Les équipes d’Asie-Pacifique poussent le code, puis celles d’Amérique du Nord prennent le relais pour générer les builds. L’environnement reste dans le datacenter, sans dépendre de l’ordinateur d’un collègue.
Une machine entière, réservée à un seul client : pas de machine virtuelle. Deux configurations Apple M4, cinq sites et une disponibilité 365 jours par an.
À partir de $19.2 par jour. Le datacenter gère l’alimentation, le réseau et le refroidissement ; votre équipe configure les pipelines, les files de build et les autorisations de publication.
Déplacez votre machine de build Xcode du bureau au datacenter. Chaque push déclenche une tâche : plus besoin de compter sur l’ordinateur laissé allumé par un collègue.
Enregistrez un runner macOS autohébergé sur la machine et configurez les branches, les cibles de test et les chemins des artefacts selon les règles du dépôt. Vérifiez d’abord qu’un build en ligne de commande fonctionne, puis activez le déclenchement automatique. Vous éviterez ainsi de confondre les problèmes d’environnement et de configuration CI.
Pour les builds séquentiels d’une seule app, commencez avec Push M4 S : M4 / 16GB / SSD 256GB. Conservez le cache des dépendances et de DerivedData pour réutiliser les mêmes répertoires lors des tâches suivantes. Évitez que plusieurs tâches écrivent simultanément dans les mêmes dossiers de sortie.
La disponibilité 365 jours par an vous évite de dépendre du datacenter ou de l’alimentation du bureau, mais ne relance pas automatiquement les tâches en échec. Le redémarrage automatique du runner, les nouvelles tentatives, le nettoyage du disque et les notifications de journaux restent à configurer dans votre pipeline.
L’exemple ci-dessous utilise App.xcworkspace et le scheme App dans le répertoire du projet. Remplacez-les par les noms réels avant l’exécution.
xcodebuild -version
xcodebuild \
-workspace App.xcworkspace \
-scheme App \
-configuration Release \
-destination 'generic/platform=iOS' \
-derivedDataPath build/DerivedData \
-archivePath build/App.xcarchive \
archivePréparez la configuration de signature à l’avance. Cette commande crée une archive ; elle ne l’exporte pas et ne la téléverse pas.
Les équipes d’Asie-Pacifique travaillent le jour ; un site de la côte est des États-Unis peut prendre le relais pour les builds et les publications pendant la journée en Amérique du Nord. Choisissez le site selon l’emplacement des principaux utilisateurs, puis transmettez les tâches via une file d’attente.
Notez la branche, le commit, le scheme, la version de Xcode et les paramètres de build. La personne qui prend le relais repart du même commit, sans devoir deviner dans l’historique des discussions quelle version a été compilée.
À transmettre : hash du commit + identifiant de tâche.
Une machine dédiée ne permet pas un nombre illimité de tâches en parallèle. Utilisez une file d’attente ou un verrou exclusif sur le même Mac et exécutez la signature et l’export l’un après l’autre. Attribuez à chaque projet ses propres répertoires de travail et clés de cache.
À transmettre : état de la file d’attente + chemin des journaux.
Avant l’approbation de publication, vérifiez les résultats des tests, l’archive et les journaux d’export. En cas d’échec, conservez l’état et les journaux d’erreur au lieu de vider immédiatement le cache et de relancer la tâche.
À transmettre : emplacement des artefacts + résultat de l’approbation.
Sites disponibles : Singapour, Tokyo, Séoul, Hong Kong et côte est des États-Unis. Pour une session VNC, privilégiez la proximité de la personne qui l’utilise ; pour les builds automatisés, tenez aussi compte du réseau entre le dépôt et les sources de dépendances. Le fuseau horaire aide à organiser les équipes, mais ne garantit pas la latence. Si les échanges intercontinentaux sont fréquents, vous pouvez configurer une machine pour chaque équipe et utiliser des labels runner cohérents.
Créez, signez et téléversez les archives destinées à l’App Store dans un environnement de build stable. Limitez les changements d’environnement et évitez de copier les certificats sur les ordinateurs de chaque collègue.
Définissez le chemin de Xcode pour la branche de publication et consignez le SDK ainsi que les fichiers de verrouillage des dépendances. Ne vous fiez pas à la version sélectionnée lors d’une précédente session graphique ; indiquez dans les journaux de build la chaîne d’outils réellement utilisée.
Conservez les certificats et profils de provisionnement sur la machine de publication et configurez le trousseau selon le principe du moindre privilège. Transmettez les mots de passe via des variables CI protégées ; ne les ajoutez ni au dépôt, ni à l’écho des commandes, ni aux journaux publics.
Conservez d’abord le xcarchive, puis exportez-le avec une configuration ExportOptions approuvée par l’équipe. Configurez séparément les autorisations et approbations de téléversement pour distinguer les échecs de compilation, de signature et de téléversement.
Associez le numéro de version, le hash du commit, les journaux de build et les artefacts. N’utilisez les certificats qu’aux endroits nécessaires et conservez-en une sauvegarde chiffrée dans un emplacement sécurisé contrôlé par l’équipe pour éviter toute perte liée à un point de défaillance unique.
Les builds iOS avec Flutter et React Native nécessitent toujours la chaîne d’outils macOS. Gardez les dépendances natives, les Pods et le cache Xcode sur la machine pour éviter de recréer l’environnement à chaque fois.
M4 / 16GB / SSD 256GB
Adapté à la CI quotidienne d’une app, à une file de publication unique et aux premiers tests de stabilité de builds multiplateformes. Le build, le simulateur et les autres processus partagent la mémoire de la machine. Commencez par les exécuter l’un après l’autre, observez les pics, puis augmentez le nombre de tâches.
Conservez les fichiers de verrouillage des dépendances et définissez des clés de cache par branche. Transférez les anciens artefacts vers votre propre stockage pour éviter que les archives finissent par saturer le disque local.
M4 / 24GB / SSD 512GB
Adapté aux archives avec plusieurs targets, aux builds Flutter / React Native mixtes et aux projets qui doivent conserver davantage de dépendances et de chaînes d’outils. Les 24GB offrent plus de marge mémoire pour les tâches simultanées, mais vérifiez le nombre de tâches en parallèle sur votre projet réel.
Suivez séparément la durée des builds, la pression mémoire et l’espace disque utilisé. Si le goulot d’étranglement vient des téléchargements entre régions ou de l’attente du verrou de signature, davantage de mémoire ne résoudra pas le problème : commencez par ajuster le cache et la file d’attente.
Si plusieurs versions de Xcode, les caches de dépendances et les archives occupent toujours plus d’espace, envisagez l’option SSD +1TB ou SSD +2TB. L’extension augmente la capacité de stockage, pas la mémoire unifiée. Identifiez d’abord ce qui occupe l’espace avant de choisir une extension.
Le même Mac cloud peut aussi exécuter des inférences de modèles en local, valider des scripts et effectuer des tests à petite échelle. Vérifiez d’abord que le modèle tient dans la mémoire unifiée, puis planifiez ces tâches en dehors des publications.
La mémoire unifiée doit aussi accueillir macOS, le framework d’inférence, le cache de contexte et les autres processus. La taille du fichier du modèle ne correspond pas à la mémoire nécessaire à son exécution. Commencez par tester avec une courte entrée, puis augmentez progressivement le contexte et la taille des lots.
À consigner : version du modèle, méthode de quantification, pic mémoire.
Fixez la version du framework, les exemples d’entrée et les paramètres de génération avant de comparer la durée et les résultats. Choisissez entre 16GB et 24GB en fonction de la stabilité d’exécution de votre tâche cible ; ne présumez pas d’une taille de modèle ni d’une vitesse universelles.
À consigner : longueur de l’entrée, paramètres d’exécution, durée.
L’inférence et la compilation Xcode sollicitent les mêmes ressources de calcul et de mémoire. Suspendez la file d’expérimentation lors d’une publication, utilisez pour les scripts des répertoires et des autorisations distincts et n’accédez pas au trousseau de publication. Enregistrez régulièrement les résultats des tâches longues.
À consigner : priorité de la tâche, condition d’arrêt, chemin des résultats.
Cette configuration convient aux tests qui nécessitent macOS et Apple Silicon, mais une petite expérimentation ne remplace pas un entraînement à grande échelle. Vous pouvez louer à la journée pour valider votre charge de travail avant de décider d’une utilisation à long terme.
Voici deux exemples de formulation selon le rôle, pour illustrer l’organisation des tâches. Ils ne correspondent ni à des avis clients vérifiés ni à des mesures réelles de performances réseau.
« Nous avons installé Fastlane sur une machine dédiée. Quelle que soit la personne de garde, elle consulte le même rapport de build : plus besoin d’attendre que quelqu’un allume son ordinateur. »
« Je teste d’abord le bureau à distance depuis le réseau de l’équipe de test, puis je choisis le site. Les tests automatisés passent par la file d’attente ; je prends le relais sur le bureau uniquement lorsqu’une vérification manuelle est nécessaire. »
Commencez avec 16GB pour les builds séquentiels d’une seule app ; évaluez 24GB pour les projets à plusieurs targets et les builds mixtes. Choisissez le site principal, puis faites tourner votre premier pipeline.
Mac mini physique dédié, à partir de $19.2 par jour. La disponibilité réelle est celle indiquée en temps réel dans la console.