Un Mac physique dédié à votre équipe. Vérifiez d’abord la connexion, fixez ensuite la chaîne d’outils, puis enregistrez le runner. Utilisez cette checklist pour les 30 premières minutes ; le téléchargement des dépendances et la durée du build complet dépendent de votre projet.
Vous n’avez pas encore loué de nœud ? Apple Silicon M4 / M4 Pro, Mac physique dédié, non virtualisé, dès $20.1/jour.
Avant d’enregistrer des tâches automatisées, assurez-vous de disposer d’une connexion graphique fonctionnelle, puis vérifiez SSH. Ne désactivez pas la connexion par mot de passe avant d’avoir testé votre unique moyen d’accès.
Connectez-vous à la console, ouvrez la page de l’instance concernée et vérifiez l’identifiant du nœud, l’adresse, le nom d’utilisateur et les instructions de connexion. Les identifiants sont consultables uniquement dans votre compte : ne les copiez ni dans un ticket, ni dans la configuration du pipeline, ni dans un dépôt de code.
Depuis la page de l’instance, ouvrez le bureau à distance dans le navigateur et vérifiez qu’il s’agit bien de l’environnement macOS de cette instance. Après la première connexion, changez le mot de passe du compte système, enregistrez-le dans le gestionnaire de mots de passe de l’équipe et désignez les responsables du renouvellement et de la rotation des identifiants.
Dans les réglages de partage de macOS, vérifiez l’option « Connexion à distance » et n’autorisez que les utilisateurs nécessaires. Connectez-vous avec l’adresse et le port indiqués dans la console ; si le port diffère de la valeur par défaut, précisez-le dans la commande ssh.
Générez une clé SSH distincte sur votre poste de travail et ajoutez uniquement la clé publique au fichier authorized_keys du nœud. Gardez la session actuelle ouverte, puis testez la connexion par clé dans un autre terminal avant de modifier les autres paramètres d’authentification.
Vérifier les autorisations sur le nœud
mkdir -p ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
whoami
sw_vers
uname -mVérification : le nom d’utilisateur doit correspondre aux identifiants de l’instance et la version du système doit répondre aux exigences du projet. Sur Apple Silicon, l’architecture affichée doit être arm64. Lors de la première connexion SSH, vérifiez l’identité de l’hôte si une empreinte vous est présentée. Ne désactivez pas la vérification de la clé d’hôte pour vous connecter.
Voici un exemple de sortie, pas le résultat réel de votre nœud. Le projet d’exemple s’appelle TeamApp ; remplacez-le par le workspace, le scheme et la configuration de signature de votre dépôt.
$ ssh "$NODE_USER@$NODE_ADDRESS"
Authenticated using "publickey".
$ uname -m
arm64
$ xcodebuild -workspace TeamApp.xcworkspace \
-scheme TeamApp -configuration Release \
-destination 'generic/platform=iOS' \
-archivePath build/TeamApp.xcarchive archive
** ARCHIVE SUCCEEDED **
$ bundle exec fastlane gym --scheme TeamApp
Successfully exported and compressed dSYM file
Successfully exported and compressed ipa file
Successfully generated ipa file:
build/TeamApp.ipaUne fois SSH opérationnel, vérifiez Ruby, Bundler et les dépendances du projet. Utilisez de préférence les versions verrouillées dans le dépôt et évitez toute commande de mise à niveau globale susceptible de modifier l’environnement de build de toute l’équipe.
Vérification : le même utilisateur peut accéder au dépôt et installer les dépendances.
Si l’archive réussit mais que l’export IPA échoue, vérifiez d’abord la méthode d’export, le certificat de signature et le profil de provisioning. Conservez la première erreur avec son contexte au lieu de ne capturer que le dernier message d’échec.
Vérification : les artefacts de build sont disponibles dans le chemin cible pour les tâches suivantes.
Le nœud est un Mac physique dédié, mais le nombre de tâches exécutables en parallèle dépend toujours de la mémoire, du stockage et de leur niveau d’isolation. Validez d’abord le processus complet avec un seul build, puis augmentez le nombre de tâches simultanées.
Dans les paramètres Actions du dépôt ou de l’organisation, ajoutez un self-hosted runner et sélectionnez macOS et ARM64. Suivez les commandes de téléchargement, de vérification et d’enregistrement affichées sur la page ; n’utilisez pas d’ancien paquet d’installation provenant d’une source inconnue.
Lors de l’enregistrement, utilisez un compte système dédié et ajoutez des tags correspondant à l’usage, comme vmfly,ios-build . Orientez le workflow vers le tag correspondant avec runs-on afin que les tâches ne s’exécutent pas dans un environnement partagé.
runs-on: [self-hosted, macOS, ARM64, vmfly, ios-build]Vérification : le runner apparaît en ligne dans l’interface d’administration et reçoit une tâche déclenchée manuellement.
Utilisez une version de Runner compatible avec votre environnement GitLab et obtenez un jeton d’authentification en suivant la procédure de création d’un runner au niveau du projet ou du groupe. Sur macOS, choisissez le shell executor et attribuez au nœud le tag macos-arm64 ainsi que des tags correspondant à son usage.
Indiquez les mêmes tags dans les tâches du pipeline. Vérifiez que le répertoire de travail du Runner appartient au compte qui l’exécute. Ce même compte doit pouvoir accéder aux certificats, au cache des dépendances et aux fichiers d’archive : vous éviterez ainsi qu’une tâche automatisée échoue alors qu’elle réussit dans le terminal interactif.
ios_archive:
tags:
- macos-arm64
- ios-build
script:
- bundle exec fastlane gymVérification : une tâche de test affiche l’architecture du système et accède à la chaîne d’outils requise par le projet.
Depuis le répertoire d’enregistrement du runner GitHub, exécutez son script de service avec ./svc.sh install et ./svc.sh start. Pour GitLab Runner, selon le mode d’installation, exécutez gitlab-runner install et gitlab-runner start. N’installez pas deux mécanismes de démarrage automatique pour un même runner.
Sur macOS, un service lancé comme LaunchAgent utilisateur dépend généralement de la session ouverte par cet utilisateur. Vérifiez la configuration réellement générée et l’identité du processus ; ne confondez pas le démarrage du Mac avec l’ouverture de session du compte de build. En l’absence de tâche de publication, vérifiez après un redémarrage que le runner se reconnecte, que les chemins sont corrects, que le trousseau est accessible et que les artefacts peuvent être exportés.
Transmettez les certificats de build et les profils de provisioning par un moyen sécurisé approuvé par l’équipe. Le certificat doit inclure la clé privée correspondante ; un certificat public importé seul ne permet pas de signer. Stockez les mots de passe de déverrouillage et les jetons d’automatisation dans les variables protégées de la CI, et limitez leur utilisation à certaines branches et tâches.
Si votre équipe utilise fastlane match, conservez ses règles de stockage et d’accès existantes. Lorsque la CI lit les éléments de signature déjà en place, privilégiez le mode lecture seule. Vérifiez la cohérence du bundle identifier, de l’équipe cible, de la méthode d’export et de la période de validité du profil de provisioning avant d’examiner la commande d’archivage.
Les tâches sans intervention doivent pouvoir accéder au trousseau prévu. N’inscrivez jamais de mot de passe permanent en clair dans un script et n’affichez pas toutes les variables d’environnement dans les logs. Avant de partager des logs, retirez les clés privées, jetons, mots de passe et contenus des éléments de signature.
Commencez par examiner l’environnement actuel du nœud, puis installez la version requise par le projet si nécessaire. Ne partez pas du principe que le Xcode sélectionné sur le bureau est celui utilisé par le processus du runner.
Vérifiez la sélection actuelle ; remplacez le chemin par le répertoire d’installation réel
xcodebuild -version
xcode-select -p
xcrun simctl list runtimes
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
xcodebuild -checkFirstLaunchStatusAttribuez des noms de fichier explicites aux différentes applications Xcode. Si plusieurs projets utilisent des versions différentes sur un même nœud, définissez de préférence DEVELOPER_DIRdans chaque tâche plutôt que de modifier la sélection globale du système à chaque build.
Vérification : la tâche exécutée par le runner affiche xcodebuild -version, et la version correspond aux exigences du projet.
Dans les réglages de Xcode, installez les runtimes requis par le projet, puis utilisez xcrun simctl list pour vérifier les appareils disponibles. Pour les tests UI, indiquez explicitement la destination afin d’éviter que la tâche attende une version du système ou un appareil inexistant.
Vérification : démarrez d’abord le simulateur cible séparément, puis lancez une suite minimale de tests UI.
Définissez un chemin DerivedData distinct pour chaque projet, conservez les caches nécessaires et fixez une durée de rétention des artefacts. Avant tout nettoyage, arrêtez les builds concernés et vérifiez le contenu et l’espace occupé ; ne lancez pas de suppression récursive directement dans un répertoire de travail partagé.
Vérification : les dépendances, le cache et les fichiers IPA ont chacun un répertoire dédié, et l’espace disque disponible suffit pour le prochain archivage.
Installez les composants nécessaires au premier lancement de Xcode avant de connecter le nœud à l’automatisation. Si le terminal interactif trouve une commande mais que la CI indique qu’elle est introuvable, comparez l’utilisateur d’exécution, PATH, le répertoire de travail et l’initialisation du shell avant de réinstaller toutes les dépendances.
Le bureau dans le navigateur convient à la configuration initiale ; pour une utilisation graphique prolongée, comparez les connexions via client. Réservez SSH et le runner aux builds sans intervention. Aucune de ces trois méthodes graphiques ne doit être l’unique emplacement de votre code et de vos artefacts.
| Mode de connexion | Utilisation conseillée | Réglages de départ | Premiers points à vérifier en cas de saccades |
|---|---|---|---|
| Bureau à distance dans le navigateur | Première connexion, réglages système, consultation ponctuelle d’un build en cours | Ouvrez la page de l’instance depuis la console ; commencez avec un seul écran et une résolution modérée | Réseau local, zoom du navigateur et nombre de sessions de bureau ouvertes simultanément |
| Client VNC | Utilisation prolongée de l’interface graphique ; réglage de l’encodage et de la qualité d’image du client | Configurez la connexion selon les instructions de l’instance ; commencez par l’encodage automatique ou une qualité équilibrée | Réduisez progressivement la qualité d’image ou la profondeur des couleurs, sans modifier plusieurs paramètres à la fois |
| Partage d’écran macOS | Dépannage du bureau et opérations d’assistance depuis un Mac local | Utilisez un mode de connexion compatible avec l’instance ; commencez en 1920 × 1080 sur un seul écran | Haute résolution, images animées et liaison entre réseaux : réduisez d’abord la résolution pour comparer |
Les saccades du bureau ne signifient pas que la compilation ralentit. Consultez la sortie des tâches et l’utilisation des ressources via SSH pour vérifier que le build progresse toujours. À l’inverse, un bureau fluide ne garantit ni une signature correcte, ni le téléchargement des dépendances, ni l’accès au dépôt distant.
En cas de problème de connexion, notez le mode utilisé, l’heure et le fuseau horaire, le type de réseau local, ainsi que l’état de la connexion SSH. Avant de modifier les réglages de connexion à distance ou de partage d’écran, gardez une session fonctionnelle ouverte afin de ne pas perdre tous vos accès.
Gérez votre compte, vos instances et vos factures depuis la console. Vérifiez d’abord les numéros de commande et d’instance avant de renouveler ou de modifier la configuration, afin de ne pas planifier une publication après la fin d’une période de location non confirmée.
Dans la console, vérifiez l’abonnement en cours, sa date d’expiration et les factures à régler. Après le paiement, confirmez à nouveau l’état de l’abonnement. Avant l’expiration, transférez le code, les sauvegardes des certificats et les artefacts de build vers un emplacement contrôlé par l’équipe ; ne considérez pas le nœud arrivant à expiration comme une sauvegarde à long terme.
À l’expiration, un nœud non renouvelé est arrêté et son disque entièrement effacé. Transférez à l’avance les données à conserver.
Glide M4 comprend une puce Apple Silicon M4, 16 Go de mémoire et un SSD de 256 Go ; Cruise M4 Pro comprend une puce Apple Silicon M4 Pro, 64 Go de mémoire et un SSD de 2 To. Avant de changer de configuration, confirmez la procédure via un ticket : il ne s’agit pas d’une mise à niveau immédiate de la mémoire de votre machine actuelle.
Vérifiez les options SSD +1 To, SSD +2 To et connexion en parallèle Thunderbolt 5 lors de la commande. Pour modifier un nœud déjà loué, confirmez d’abord la procédure par ticket.
Seuls les paiements en USDT-TRC20 et par Visa / Mastercard / Amex (via Stripe) sont acceptés ; tous les montants sont facturés en dollars américains. Les moyens effectivement disponibles dépendent de la réponse de la passerelle. L’attribution du Mac physique commence uniquement après confirmation du paiement.
Si le statut du paiement n’est pas à jour, joignez le numéro de commande et le justificatif de paiement ; pour un paiement en USDT, ajoutez également le hash de transaction. Ne payez pas une seconde fois et ne communiquez jamais votre numéro de carte complet.
Si vous avez déjà un compte, ouvrez et suivez votre ticket depuis la console. Indiquez l’identifiant du nœud, l’heure et le fuseau horaire de l’erreur, les étapes pour la reproduire et des extraits de logs expurgés. Pour une demande avant-vente ou si vous ne pouvez pas vous connecter, retrouvez support@vmfly.com sur la page de contact.
Précisez le résultat attendu et le résultat obtenu, et indiquez si SSH, le bureau et le runner sont toujours accessibles. N’incluez ni mot de passe, ni clé privée, ni données complètes de carte bancaire.