Connectez-vous, puis migrez

Votre Mac cloud connecté en trois minutes

Exécutez vos commandes en SSH et utilisez l’interface graphique de macOS via VNC. Vous disposez d’une machine physique dédiée, pas d’une machine virtuelle. Migrez le code source, la chaîne d’outils et la CI étape par étape, sans transférer les problèmes de votre environnement local.

Louer un Mac cloud Voir les infos de connexion

Si vous avez reçu les informations de connexion et ajouté votre clé SSH publique, suivez les étapes ci-dessous. La configuration initiale de la chaîne d’outils prend du temps en plus et ne fait pas partie des étapes de connexion.

Commencez par SSH : toutes les étapes suivantes passent par ce canal

Préparez un terminal local, votre clé SSH publique et les informations de la machine indiquées dans le portail. Dans les exemples, remplacez HOST, PORT et USER par l’adresse de la machine, le port SSH et le nom d’utilisateur qui vous ont été fournis. Ne copiez pas ces valeurs telles quelles.

01 · Préparation locale

Ajoutez la clé publique, jamais la clé privée

Vous avez déjà une clé dédiée ? Utilisez-la. Sinon, générez une paire de clés Ed25519 sur votre ordinateur, définissez une phrase secrète, puis ajoutez le contenu du fichier .pub dans la section des clés SSH du portail.

ssh-keygen -t ed25519 \
  -f ~/.ssh/osxbuild_ed25519

cat ~/.ssh/osxbuild_ed25519.pub

Gardez la clé privée sur votre ordinateur. Ne la collez ni dans un ticket, ni dans un e-mail, ni dans un dépôt. Après l’ajout, vérifiez dans le portail que la clé publique est bien associée à l’instance cible.

02 · Vérification

Testez une première connexion avec le port fourni

Récupérez les informations de connexion dans les détails de l’instance du portail. Lors de la première vérification de l’empreinte de l’hôte, comparez-la aux informations reçues. En cas de doute, ouvrez un ticket plutôt que de désactiver la vérification pour ignorer l’avertissement.

ssh -i ~/.ssh/osxbuild_ed25519 \
  -p PORT USER@HOST

sw_vers
uname -m
xcodebuild -version

Vérifiez d’abord le système, l’architecture et la version de Xcode. Si la dernière commande indique que la chaîne d’outils n’est pas prête, installez-la et sélectionnez le bon chemin avant de lancer vos builds.

03 · Accès simplifié

Attribuez un alias local à la machine

Ajoutez le bloc ci-dessous à votre fichier local ~/.ssh/config. L’alias de l’exemple est bake ; les commandes de synchronisation, de tunnel et de diagnostic le réutilisent pour éviter de saisir l’adresse et le port à chaque fois.

Host bake
  HostName HOST
  Port SSH_PORT
  User SSH_USER
  IdentityFile ~/.ssh/osxbuild_ed25519
  IdentitiesOnly yes
  ServerAliveInterval 30
  ServerAliveCountMax 3

Enregistrez le fichier, puis exécutez ssh bake. Les paramètres de keepalive permettent de détecter les connexions interrompues ; ils ne rétablissent pas le réseau et ne relancent pas les tâches du terminal.

Utilisez VNC pour le bureau graphique et un tunnel SSH pour y accéder

Ouvrez le bureau uniquement si vous devez configurer Xcode, vérifier le trousseau ou consulter un simulateur. Commencez par vérifier les informations du service VNC fournies dans le portail. Ne partez pas du principe que le port par défaut est celui de votre machine.

Choisissez un client que vous connaissez

Sur macOS, utilisez « Partage d’écran ». Sous Windows et Linux, vous pouvez utiliser le client TigerVNC compatible avec VNC. Si vous devez installer un client, téléchargez-le depuis le site officiel de son éditeur et vérifiez qu’il prend en charge le mode d’authentification du service fourni.

Réduisez le débit avant d’ajuster la qualité

Commencez avec une résolution de 1440 × 900 ou 1600 × 1000, sans passer directement en plein écran sur un écran haute résolution. Si le réglage est disponible, essayez d’abord une profondeur de couleur de 24 bits, puis 16 bits si le réseau est limité. Les options dépendent des capacités du client et du serveur.

Le terminal et le bureau distant sont deux modes d’utilisation distincts. Si le bureau manque de fluidité, lancez vos builds en SSH et récupérez les journaux et les fichiers IPA. Vous n’avez pas besoin de faire dépendre toute la pipeline du rafraîchissement de l’écran.

Redirigez le port du bureau vers votre machine locale

Exécutez la commande ci-dessous en local et laissez le terminal ouvert. Remplacez VNC_PORT par le port du service qui vous a été fourni. Dans l’exemple, 15900 est le port local : vous pouvez le remplacer par un port disponible.

ssh -N \
  -L 127.0.0.1:15900:127.0.0.1:VNC_PORT \
  -o ExitOnForwardFailure=yes \
  bake

Dans le client VNC, indiquez 127.0.0.1 dans le champ de l’adresse et 15900 dans celui du port. Si le client utilise un seul champ, suivez le format indiqué dans sa documentation.

VNC utilise toujours les identifiants de bureau fournis ; votre clé SSH ne remplace pas le mot de passe du bureau. Une fois terminé, quittez le client puis fermez le tunnel avec Ctrl + C.

Le bureau ne se connecte pas ? Vérifiez chaque étape du chemin de connexion
Symptôme	À vérifier d’abord	Étape suivante
Impossible d’ouvrir le port local	La connexion SSH est-elle établie ? Le port local est-il déjà utilisé ?	Essayez un autre port local et conservez le message d’erreur du terminal où le tunnel est ouvert.
Le tunnel est établi, mais le bureau refuse la connexion	Le port VNC fourni et l’état du service en écoute	Vérifiez les détails de l’instance. N’exposez pas le port du bureau sur Internet.
Échec après l’étape d’authentification	Le nom d’utilisateur et le mot de passe du bureau, ainsi que la compatibilité de l’authentification du client	Vérifiez à nouveau les identifiants fournis. N’utilisez pas la clé privée SSH comme mot de passe VNC.
La connexion fonctionne, mais l’affichage est lent	La résolution, la profondeur de couleur, le réseau local et la distance au nœud	Réduisez le volume de données affichées et poursuivez le build en SSH s’il ne nécessite pas d’interface graphique.

Migrez en trois étapes, sans copier tout le disque

Commencez par les données, alignez ensuite la chaîne d’outils, puis configurez la CI. Validez chaque étape avec un résultat concret : réalisez d’abord une archive propre, puis restaurez les caches et l’automatisation.

Étape 1 · Données

Synchronisez le code et recréez les fichiers temporaires

Clonez le projet avec Git ou synchronisez votre répertoire de travail local et les ressources hors dépôt avec rsync. Pour le premier transfert, excluez DerivedData et les anciens répertoires build. Ne synchronisez pas les clés privées de signature avec les fichiers courants.

rsync -az --progress \
  --exclude='DerivedData/' \
  --exclude='build/' \
  --exclude='*.p12' \
  --exclude='*.mobileprovision' \
  ./ bake:~/project/

Validation : vérifiez le répertoire cible, la révision du dépôt et la présence des ressources nécessaires. L’exemple ne comporte pas d’option de suppression afin d’éviter d’effacer des fichiers distants lors du premier transfert. Une synchronisation réussie ne constitue pas une sauvegarde.

Étape 2 · Chaîne d’outils

Alignez les versions avant de restaurer les dépendances

Installez ou sélectionnez la version de Xcode requise par le projet et configurez Homebrew. Restaurez CocoaPods à partir du fichier de verrouillage et relancez la résolution des dépendances SPM. Les caches doivent correspondre aux versions de la chaîne d’outils et des dépendances ; ne réutilisez pas de répertoires dont l’origine est inconnue.

xcode-select -p
xcodebuild -version
brew --version

bundle install
bundle exec pod install

Validation : les versions correspondent à votre environnement de référence et les dépendances se résolvent correctement. Exécutez les deux dernières commandes uniquement pour les projets CocoaPods. Importez le certificat de signature dans le trousseau via un canal sécurisé, puis vérifiez sa validité et sa correspondance avec le profil de provisioning.

Étape 3 · CI

Enregistrez le runner, puis configurez la distribution

Enregistrez un runner dédié dans GitHub Actions ou GitLab Runner. Vérifiez d’abord les versions, puis exécutez le lane Fastlane du projet. Validez la création de l’archive et son export avant d’ajouter l’étape de téléversement.

xcodebuild -list \
  -workspace App.xcworkspace

bundle exec fastlane ios build

Validation : les journaux permettent de retrouver la révision, le Scheme et le chemin de l’archive. Remplacez le nom de l’espace de travail et du lane de l’exemple par ceux du projet. Autorisez séparément les identifiants de publication et ne les distribuez pas avec le code source.

Avec la CI, dirigez explicitement les tâches vers cette machine

Un runner auto-hébergé s’exécute sur le nœud physique que vous louez. Les labels orientent les tâches ; les identifiants gèrent les autorisations. Ne confondez pas les deux. Commencez par faire fonctionner une seule tâche, puis évaluez le parallélisme et l’espace disque.

GitHub Actions : ciblez le runner avec un label dédié

Suivez les instructions dans les paramètres du dépôt ou de l’organisation pour enregistrer un runner self-hosted, puis ajoutez le label personnalisé osxbuild. Le workflow ci-dessous vérifie la chaîne d’outils et crée une archive ; il n’injecte pas les éléments de signature, n’exporte pas d’IPA et ne distribue pas l’application.

name: iOS archive
on:
  workflow_dispatch:

permissions:
  contents: read

concurrency:
  group: ios-${{ github.ref }}
  cancel-in-progress: false

jobs:
  archive:
    runs-on: [self-hosted, macOS, ARM64, osxbuild]
    steps:
      - uses: actions/checkout@v4
      - name: Check Xcode
        run: xcodebuild -version
      - name: Archive
        run: |
          xcodebuild \
            -workspace App.xcworkspace \
            -scheme App \
            -configuration Release \
            -archivePath "$RUNNER_TEMP/App.xcarchive" \
            archive

Remplacez l’espace de travail et le Scheme, et vérifiez que le Scheme est partagé. Réservez le runner qui détient des éléments de signature aux dépôts et tâches de confiance. Chaque branche ayant son propre groupe de concurrence, veillez malgré tout à éviter les conflits dans les répertoires de build partagés.

Jenkins : lancez un agent dédié via SSH

Dans Jenkins, ajoutez un nœud permanent et définissez un répertoire de build dédié comme répertoire de travail distant. Attribuez-lui le label osxbuild-mac. Choisissez le lancement de l’agent via SSH, indiquez l’hôte et le port fournis et gérez la clé privée dans le magasin d’identifiants Jenkins.

pipeline {
  agent { label 'osxbuild-mac' }

  stages {
    stage('Checkout') {
      steps {
        checkout scm
      }
    }
    stage('Toolchain') {
      steps {
        sh 'xcodebuild -version'
      }
    }
    stage('Build') {
      steps {
        sh 'bundle exec fastlane ios build'
      }
    }
  }
}

Vérifiez que Java est disponible pour l’agent, que les identifiants SSH sont valides et que l’empreinte de l’hôte a été vérifiée. Un environnement non interactif lancé via SSH ne charge pas toujours la configuration locale du shell : configurez explicitement les chemins de Homebrew, Ruby et Fastlane.

Pour GitLab Runner, suivez le même ordre : enregistrez le runner, limitez son usage aux projets de confiance, définissez un label de projet, puis validez l’environnement avec une tâche de vérification des versions. Si vos tests nécessitent une session graphique, vérifiez d’abord les conditions d’exécution séparément.

Commencez avec un seul slot d’exécution. Avant d’augmenter le parallélisme, vérifiez les pics de mémoire, le nombre de simulateurs et le chemin de DerivedData. Plusieurs tâches ne doivent pas écrire dans le même répertoire d’archive.

Six nœuds : choisissez selon les personnes qui utiliseront la machine

Si vous utilisez souvent le bureau graphique, comparez en priorité le chemin de connexion entre votre équipe et les nœuds. Pour la CI, examinez plutôt les transferts du code source, des dépendances et des artefacts. La distance géographique n’est qu’un premier repère : l’opérateur, le routage et votre réseau local comptent aussi.

Singapour

SG · UTC+8

Adapté aux équipes travaillant sur les fuseaux horaires d’Asie du Sud-Est. Si vous utilisez fréquemment Xcode à distance en journée, comparez d’abord la qualité de connexion depuis votre emplacement.

Choisir Singapour

Tokyo

JP · UTC+9

Adapté aux équipes travaillant sur les fuseaux horaires d’Asie de l’Est. Regroupez le développement interactif en journée et les archives de nuit sur la même machine pour simplifier le relais.

Choisir Tokyo

Séoul

KR · UTC+9

Adapté aux équipes travaillant sur les fuseaux horaires de l’Asie du Nord-Est. Si vous utilisez souvent le bureau distant, évaluez d’abord la fluidité de l’affichage et la réactivité des commandes, puis définissez un point d’accès commun.

Choisir Séoul

Hong Kong

HK · UTC+8

Adapté aux équipes travaillant sur les fuseaux horaires du sud de la Chine et de l’Asie du Sud-Est. Évaluez les interactions à distance, mais aussi le téléchargement des dépendances et l’envoi des artefacts : une seule vérification de connexion ne suffit pas.

Choisir Hong Kong

Est des États-Unis

US-E · UTC−5 / −4

Adapté aux équipes de l’est de l’Amérique du Nord et d’Europe occidentale. Pour planifier les builds nocturnes, définissez explicitement le fuseau horaire et tenez compte du passage à l’heure d’été.

Choisir l’est des États-Unis

Ouest des États-Unis

US-W · UTC−8 / −7

Adapté aux équipes de la côte ouest de l’Amérique du Nord. Alignez les builds sur les jours ouvrés locaux et indiquez clairement les heures dans les journaux lors des relais entre fuseaux horaires.

Choisir l’ouest des États-Unis

Les deux configurations sont disponibles sur ces six nœuds. Consultez le portail pour connaître les disponibilités en temps réel. Les nœuds fonctionnent normalement 365 jours par an ; distinguez l’état de la machine d’une coupure de votre réseau local ou d’une interruption de la session SSH.

Une fois connecté, sécurisez les accès et les éléments de signature

Conservez d’abord une connexion dont le bon fonctionnement a été vérifié, puis ajustez les règles d’accès. Ne modifiez qu’un paramètre à la fois et vérifiez que la nouvelle connexion fonctionne avant de fermer l’ancienne, pour éviter de perdre l’accès à la machine.

01
Vérifiez la clé avant de désactiver l’authentification par mot de passe

Ouvrez un deuxième terminal et vérifiez que la connexion avec la clé dédiée fonctionne. Désactivez ensuite l’authentification par mot de passe selon la configuration SSH du système. Vérifiez la syntaxe avant toute modification et assurez-vous de pouvoir rétablir la connexion. Si vous ne maîtrisez pas les réglages du système, ouvrez un ticket pour confirmer la marche à suivre.
02
N’ouvrez que les ports nécessaires

Limitez les points d’accès SSH et aux services au strict nécessaire, et privilégiez un tunnel SSH pour VNC. Évitez d’exposer directement sur Internet des services de diagnostic, des interfaces de contrôle du build ou des serveurs de fichiers temporaires. Vérifiez ensemble l’adresse d’écoute locale et les règles de contrôle d’accès.
03
Une clé distincte par personne et par usage

Utilisez des clés différentes pour les connexions manuelles et la CI. Révoquez immédiatement les anciennes autorisations en cas de changement d’équipe ou de suspicion de fuite. Pour renouveler une clé, ajoutez et vérifiez d’abord la nouvelle clé publique, supprimez l’ancienne ensuite, puis mettez à jour les runners et les consignes de passation.
04
Ne divulguez pas les éléments de signature dans les journaux courants

Déverrouillez le trousseau uniquement pour le build et limitez-en l’accès une fois l’opération terminée. Injectez la clé API, le mot de passe du certificat et les identifiants de déchiffrement de match via un gestionnaire d’identifiants. Vérifiez que les scripts n’affichent pas de variables sensibles et ne stockez pas de fichiers de clé privée dans le dépôt.
05
Récupérez les artefacts et la configuration avant la fin de la location

Synchronisez le code source, les fichiers IPA, les archives et la configuration des pipelines à conserver vers un stockage appartenant à votre équipe, puis vérifiez que les fichiers sont lisibles. À la fin de la location, le disque est effacé et le système réinstallé : ne gardez pas l’unique copie de vos fichiers sur la machine.

Pour obtenir de l’aide, transmettez les informations de diagnostic nécessaires. Dans votre ticket, indiquez le numéro de commande, le nœud, l’heure et le fuseau horaire de l’erreur, ainsi que les 50 dernières lignes des journaux après suppression des données sensibles. N’envoyez ni clé privée, ni mot de passe de certificat, ni mot de passe de compte. Pour un problème de connexion, contactez-nous via un ticket du portail ou à l’adresse support@osxbuild.com.

Définissez votre méthode de connexion avant le prochain archive

Vous avez déjà une machine ? Vérifiez les informations fournies dans le portail. Vous n’avez pas encore choisi de configuration ? Commencez par l’une des deux offres de Mac cloud dédié, choisissez la machine selon le volume de builds, puis le nœud selon l’emplacement de votre équipe.

Choisir un Mac cloud Se connecter au portail et ouvrir un ticket