De la commande à la première archive

Intégrez votre Mac dans le cloud à votre processus de build Xcode

Ce guide couvre le choix de la configuration, la commande, la connexion, l’initialisation de l’environnement, la première archive et l’intégration d’un runner CI. Suivez les étapes dans l’ordre : faites d’abord fonctionner une chaîne de publication reproductible, puis ajoutez la concurrence et la mise en cache.

Louer immédiatement un Mac dans le cloud Voir les configurations et les tarifs

3 configurations: Configurations fixes
4: Régions disponibles
$20.7/jour: Prix d’appel minimum

BUILD RUN SHEET Première archive iOS

Prêt à exécuter

Dépôt de code Nœud dédié Artefact d’archive

01
Confirmer la configuration et le nœudVérifiez la configuration, la durée, la ville et l’extension de stockage
02
Initialiser l’environnement XcodeVérifiez la version, les outils en ligne de commande, Git et le gestionnaire de dépendances
03
Exécuter la première archiveFixez le scheme, les paramètres de signature et les options d’exportation
04
Enregistrer le runner CIIsolez le répertoire de travail et définissez les règles de nettoyage après le build

SG Singapour JP Tokyo KR Séoul HK Hong Kong

Étape 01

Verrouillez cinq éléments avant de commencer

La vitesse de livraison dépend moins du nombre d’outils installés que de la validation préalable des droits de compte, des autorisations du dépôt, de la version Xcode, du nœud et de la durée de location.

Droits du développeur

Vérifiez que votre compte Apple Developer dispose de l’équipe cible ainsi que des droits nécessaires pour les certificats, les profils de provisioning et la publication. N’attendez pas la fin de l’archive pour contrôler l’accès à la signature.

Accès au dépôt

Préparez des identifiants de déploiement avec les privilèges minimaux et vérifiez l’accès au dépôt principal, aux dépendances privées, aux sous-modules et au stockage de fichiers volumineux. Ne réutilisez pas vos identifiants personnels permanents pour la CI.

Version Xcode

Précisez la version majeure et le numéro de build requis par le projet, puis vérifiez la compatibilité de Swift, du SDK et des outils en ligne de commande. La version du runner doit être fixe : ne dépendez pas d’un changement temporaire.

Emplacement du nœud

Parmi Singapour, Tokyo, Séoul et Hong Kong, privilégiez le nœud proche des principaux développeurs, du dépôt de code et des sources de dépendances, puis validez votre choix avec une connexion réelle.

Durée de location

Pour une validation de signature ponctuelle, commencez à la journée ou à la semaine ; le développement continu et un runner fixe conviennent mieux à une durée mensuelle ou trimestrielle. Choisissez selon votre plan de build réel, sans estimer un taux d’utilisation théorique.

Étape 02

Choisissez la configuration selon la charge, pas selon le nom du projet

Les trois configurations sont des machines physiques dédiées Apple Silicon, et non des machines virtuelles. Tenez surtout compte du nombre de tâches parallèles, du volume des dépendances, de la taille du cache et des besoins en mémoire unifiée.

Build léger

Go M4 Core

Convient à la validation d’un projet unique, aux signatures ponctuelles, aux builds Xcode peu parallèles et aux tâches courtes nécessitant un environnement dédié.

Puce: M4
Mémoire: 16GB
Stockage: 256GB

Choisir Go M4 Core

Développement quotidien

Go M4 Plus

Convient à plusieurs projets courants, à l’installation de dépendances React Native ou Flutter et aux files d’intégration continue avec une concurrence modérée.

Puce: M4
Mémoire: 24GB
Stockage: 512GB

Choisir Go M4 Plus

Charge mémoire élevée

Go M4 Pro

Convient aux builds fortement parallèles, aux grands caches de dépendances et aux expérimentations d’inférence IA exigeant davantage de mémoire unifiée et de stockage local.

Puce: M4 Pro
Mémoire: 64GB
Stockage: 2TB

Choisir Go M4 Pro

Étape 03

Validez quatre groupes de paramètres lors de la commande

Le configurateur regroupe l’hôte, la durée, le nœud et les options dans une seule commande. Vérifiez chaque ligne avant l’envoi pour éviter de migrer les données une fois l’environnement créé.

Checklist des paramètres de commande Contrôle avant envoi

HOST

Choisissez l’une des trois configurations principales

Les caractéristiques de la puce, de la mémoire et du disque système sont celles indiquées sur la carte de configuration.

TERM

Choisissez un jour, une semaine, un mois ou un trimestre

La durée des options doit correspondre à celle de l’hôte.

NODE

Choisissez l’un des quatre nœuds disponibles

Singapour, Tokyo, Séoul et Hong Kong sont disponibles dans le configurateur.

ADD

Ajoutez des extensions selon la tâche

Vous pouvez ajouter +1TB SSD, +2TB SSD ou Thunderbolt 5 en parallèle pour chaque machine.

Choix du nœud

Privilégiez d’abord la proximité du flux de travail

L’expérience du bureau distant dépend davantage de la liaison entre le développeur et le nœud ; la vitesse de récupération des dépendances dépend aussi de l’emplacement du dépôt et des sources de téléchargement. Sélectionnez d’abord des nœuds candidats, puis testez-les avec un projet réel.

Voir les informations sur les nœuds

Disponibilité

L’état renvoyé en temps réel par la console fait foi

Toutes les combinaisons du catalogue peuvent faire l’objet d’une commande ; leur disponibilité réelle au moment de la création est renvoyée en temps réel par la console. Ne déduisez pas l’état actuel d’une capture d’écran.

Configurer la commande

Étape 04

Validez d’abord l’interface graphique, puis automatisez

À réception des informations de livraison, vérifiez d’abord le bureau, le clavier, le réseau et l’état du système via VNC. Une fois l’environnement de base validé, utilisez SSH pour exécuter les scripts et les tâches du runner.

Connexion 01

Validez le bureau avec VNC

Vérifiez la résolution, la disposition du clavier, le presse-papiers, le fuseau horaire et l’accès réseau. Lors de la première validation, évitez de modifier de nombreux paramètres système à la fois afin de faciliter l’identification des variables en cas de problème.

Notez l’adresse du nœud et l’heure de connexion
Vérifiez que la session de bureau reste utilisable
Testez les téléchargements de base et l’accès au dépôt

Connexion 02

Confiez les tâches répétitives à SSH

Transformez la récupération du code, l’installation des dépendances, le nettoyage du cache et l’exécution des builds en scripts reproductibles. Utilisez des identifiants aux privilèges minimaux et stockez-les séparément des journaux et des artefacts de build.

Limitez les projets accessibles par la clé
Fixez le point d’entrée du script et le répertoire de travail
Conservez le code de sortie et les journaux des commandes en échec

Étape 05

Initialisez un environnement de développement reproductible

Vérifiez d’abord le système et Xcode, puis installez les outils du projet. Conservez la sortie de version de chaque étape afin que le runner puisse ensuite déterminer si une différence vient du code ou de l’hôte.

Commandes de vérification de l’environnement ENV-CHECK

$ sw_vers Vérifier la version de macOS

$ xcodebuild -version Vérifier Xcode et la version de build

$ xcode-select -p Vérifier le chemin des outils en ligne de commande

$ git --version Vérifier que Git est disponible

$ fastlane --version Vérifier la version de l’outil d’automatisation

01
Vérifier le compte système
Vérifiez l’utilisateur actuel, le répertoire personnel, les droits administrateur et l’emplacement des volumes montés. Ne dispersez pas le répertoire du projet sur le bureau ou dans un dossier de téléchargement temporaire.
02
Effectuer le premier lancement de Xcode
Ouvrez la version Xcode cible, acceptez l’installation des composants requis et vérifiez que les outils en ligne de commande pointent vers cette même version.
03
Installer la chaîne de dépendances du projet
Installez le gestionnaire de paquets et les dépendances selon les fichiers de verrouillage du projet ; ne mettez pas à niveau aveuglément les versions verrouillées lors du premier build.
04
Fixer Fastlane et les points d’entrée des scripts
Utilisez les contraintes de version du projet et séparez le build, les tests, l’archive et la distribution en tâches pouvant être relancées indépendamment.

Étape 06

Pour la première compilation Xcode dans le cloud, validez une seule chaîne principale

L’objectif du premier passage n’est pas la vitesse maximale, mais l’obtention d’un artefact vérifiable depuis un répertoire propre. Fixez la version du dépôt, le scheme, la signature et le mode d’exportation, puis optimisez le cache.

Récupérer une version déterminée

Utilisez une branche, un tag ou un identifiant de commit explicite. Synchronisez les sous-modules et les fichiers de verrouillage des dépendances, puis consignez le commit associé à ce build.

Vérifier le scheme

Commencez par xcodebuild -list pour vérifier les schemes disponibles et confirmer que le scheme cible est partagé et adapté à un build en ligne de commande.

Vérifier les éléments de signature

Contrôlez les certificats, les profils de provisioning, le Bundle Identifier et les droits de l’équipe. Ne stockez jamais le mot de passe de signature dans le dépôt ni dans les journaux de build ordinaires.

Exécuter l’archive

Précisez le workspace ou le project, le scheme, la configuration et le chemin d’archive ; en cas d’échec, conservez le code de sortie complet et les journaux.

Vérifier l’artefact exporté

Contrôlez le nom de l’artefact, le numéro de version, le numéro de build, le résultat de la signature et la taille du fichier, puis vérifiez que la chaîne de distribution TestFlight peut le recevoir.

Critère de réussite Le même commit doit produire une archive valide avec la même commande

À optimiser plus tard La concurrence, le taux de succès du cache et la vitesse des builds incrémentiels

Étape 07

Donnez au runner self-hosted le contrôle du build

Enregistrez le runner seulement après avoir réussi la première archive. L’essentiel n’est pas d’être « en ligne », mais d’isoler les répertoires de travail, de définir des labels clairs, de limiter les droits du projet et de pouvoir restaurer l’environnement après chaque tâche.

Répertoire de travail

Un chemin dédié par runner

Gérez séparément le code source, DerivedData, le cache des dépendances et les artefacts exportés. Ne laissez pas plusieurs tâches parallèles écrire dans le même chemin d’archive.

Conception des labels

Les labels décrivent les capacités, pas les tâches temporaires

Les labels peuvent indiquer la région, la version majeure de Xcode et le niveau de charge. Évitez d’y inscrire le nom du projet, d’une personne ou d’une branche temporaire.

Périmètre d’accès

N’autorisez que les projets nécessaires à l’exécution

Limitez les dépôts et les variables accessibles par le runner. Séparez les éléments de signature de production et les droits de build de test selon le workflow.

Règles de nettoyage

Supprimez les éléments sensibles résiduels après chaque tâche

Supprimez les identifiants temporaires, les configurations d’exportation et les artefacts inutiles ; gérez le cache par répertoire, capacité et date de dernière modification, sans tout effacer indistinctement.

Étape 08

Effectuez le dernier contrôle de livraison avant la mise en production

Ajoutez les points ci-dessous au manuel d’exploitation de l’équipe. Une fois les contrôles validés, le runner pourra prendre en charge les builds continus et les distributions TestFlight.

Certificats et profils de provisioning

Vérifiez la période de validité, l’équipe associée, le Bundle Identifier et le périmètre d’utilisation, puis notez le responsable de la mise à jour.

Espace disque disponible

Contrôlez l’espace occupé par le code source, DerivedData, le cache des dépendances, les archives et les artefacts exportés, et prévoyez une marge pour les builds successifs.

Stratégie de cache

Définissez les répertoires réutilisables, leur expiration, la capacité maximale et les conditions de nettoyage. Ne mettez jamais en cache les mots de passe de signature ni les jetons temporaires.

Chaîne TestFlight

Réalisez une validation de bout en bout, de l’export de l’archive à la fin de l’envoi, et vérifiez la cohérence du numéro de version, du numéro de build et du journal de publication.

Nettoyage des informations sensibles

Examinez le dépôt, les fichiers d’environnement, l’historique des commandes et les journaux de build, puis supprimez les clés, jetons et mots de passe de signature qui ne doivent pas être conservés durablement.

Procédure d’escalade en cas d’échec

Notez le numéro de commande, le nœud, l’heure de reproduction, les journaux d’erreur et les étapes déjà exécutées ; si vous avez besoin d’aide, envoyez un ticket depuis la console.

READY Build initial reproductible, droits du runner contrôlés et informations sensibles supprimées

Ouvrir la console pour envoyer un ticket

Une fois prêt, commencez par un nœud dédié

Choisissez la configuration, la durée et le nœud, réussissez d’abord la première archive Xcode, puis intégrez la commande stabilisée à la file CI.

Louer immédiatement un Mac dans le cloud Comparer les trois configurations