Dépanner un build CI iOS trop long : guide capacité Mac 2026

Un build CI iOS dépasse le délai alors qu’un Mac semble disponible dans la console.

La solution la plus rapide n’est pas d’ajouter immédiatement un nœud : commencez par isoler l’attente, le routage, les dépendances, xcodebuild, le simulateur, la signature et la publication. L’extension de capacité ne devient pertinente que si des nœuds sains restent occupés, que la file augmente avec la concurrence et que la durée d’exécution d’une tâche ne présente pas d’anomalie propre.

Cette méthode s’adresse aux responsables IT qui doivent vérifier qu’une nouvelle ressource Mac répond réellement au problème. Elle convient aussi aux responsables plateforme qui veulent relier l’état du runner aux étapes du build, ainsi qu’aux responsables de publication qui cherchent à réduire les attentes lors des mises en production.

[ SECTION_01 ] Le dépassement de délai doit être transformé en preuve exploitable

Le temps total affiché par une pipeline ne dit pas où elle a attendu. Une tâche peut rester dans une file, ne trouver aucun Mac Runner compatible, télécharger une dépendance privée, bloquer sur un certificat ou attendre une publication. Ces causes n’appellent pas la même correction.

La première action consiste à créer une ligne temporelle par exécution. Elle doit contenir au minimum :

• l’heure d’entrée dans la file ;
• l’heure à laquelle un runner accepte la tâche ;
• le début de la préparation du code et des dépendances ;
• le lancement de xcodebuild ;
• l’ouverture du simulateur ou l’exécution des tests ;
• le début de la signature ;
• la transmission des artefacts ;
• la fin du workflow ou son dernier message connu.

Les journaux de l’orchestrateur, du Mac et de la compilation doivent être conservés ensemble. La référence officielle de xcodebuild permet de rattacher les commandes exécutées aux messages produits par l’outil, tandis que la documentation sur les résultats de test Xcode aide à distinguer une compilation terminée d’une phase de test encore active.

Attention : un délai global ne doit jamais être utilisé seul pour décider d’un achat. Le responsable doit d’abord savoir si le Mac a reçu la tâche et quelle étape a produit le dernier événement vérifiable.

Une panne de capacité produit généralement un signal de concurrence. Une panne de dépendance produit plutôt des répétitions, des délais réseau ou une étape identique qui s’allonge. Une panne de routage peut laisser un nœud visiblement inactif tout en empêchant la tâche de l’atteindre.

[ SECTION_02 ] Le routage et la file doivent être contrôlés avant les ressources matérielles

Un Mac Runner « disponible » n’est pas nécessairement éligible. L’orchestrateur peut exiger une étiquette, un groupe, une architecture, un outil installé ou une autorisation particulière. La documentation des runners auto-hébergés décrit ce principe de sélection par caractéristiques et par état.

Le contrôle doit suivre cette séquence :

1. Vérifier que le runner est connecté et qu’il reçoit bien les événements de supervision.
2. Comparer les étiquettes demandées par le workflow avec celles réellement attribuées au nœud.
3. Contrôler le groupe de runners et les droits associés au dépôt ou au projet.
4. Rechercher une limite de concurrence au niveau du workflow, du projet ou de l’organisation.
5. Vérifier si une tâche amont doit se terminer avant le lancement du build iOS.
6. Comparer l’heure d’acceptation de la tâche avec l’heure d’entrée dans la file.
7. Rejouer une tâche minimale sur le même chemin de routage.

Les règles d’application des étiquettes aux runners sont particulièrement importantes lorsque plusieurs Mac possèdent des versions d’outils ou des profils de signature différents. Une étiquette trop restrictive peut créer une file artificielle. Une étiquette trop large peut envoyer un build vers un environnement qui ne possède pas le bon Xcode ou les bons secrets.

La documentation sur l’utilisation des runners dans un workflow doit être consultée pour vérifier la correspondance entre la définition du workflow et les propriétés attendues du nœud. Le responsable ne doit pas conclure à un manque de Mac tant que cette correspondance n’est pas démontrée.

[ SECTION_03 ] Les dépendances créent souvent un faux diagnostic de saturation

Une pipeline peut consommer très peu de ressources locales tout en dépassant son délai. Les causes fréquentes se trouvent avant ou autour de la compilation :

• dépôt Git lent ou inaccessible ;
• objets Git LFS récupérés plusieurs fois ;
• dépendance Swift Package non disponible ;
• registre privé soumis à une authentification expirée ;
• proxy ou pare-feu qui ralentit certaines requêtes ;
• cache non disponible sur un nouveau nœud ;
• changement de version qui invalide les artefacts précédents ;
• service Apple ou service de publication momentanément inaccessible.

Le diagnostic doit séparer le premier téléchargement d’une exécution avec cache. Il faut également enregistrer le nombre de tentatives et le volume de données transféré lorsque ces informations sont disponibles. Un cache peut accélérer une donnée reconstruisible. Il ne corrige ni une permission incorrecte, ni une adresse privée inaccessible, ni une version de dépendance qui change à chaque exécution.

Une bonne expérience consiste à exécuter la même révision sur un nœud déjà utilisé et sur un nœud nouvellement ajouté. Si seul le nouveau nœud est lent, la cause peut être le cache, la configuration réseau, le trousseau ou l’initialisation de l’environnement. Si les deux nœuds présentent le même ralentissement à la même étape, ajouter des machines ne traite probablement pas la cause.

Pour les équipes qui structurent une architecture CI/CD iOS pour plusieurs développeurs, cette comparaison doit être intégrée à la collecte standard. Chaque étape doit exposer un début, une fin, un résultat et un lien vers le journal correspondant.

[ SECTION_04 ] Xcode, simulateur et signature doivent être examinés séparément

La compilation n’est qu’une partie du parcours. Le système de build Xcode peut générer, réutiliser ou invalider des produits intermédiaires selon les paramètres du projet. La documentation du système de build Xcode fournit le cadre nécessaire pour interpréter les opérations de compilation et leurs dépendances.

Le responsable doit rechercher quatre profils distincts.

Une seule tâche est anormalement lente

Si un seul projet ou une seule révision ralentit, il faut examiner les changements de code, les scripts, les dépendances et les réglages de compilation. Une forte utilisation du processeur sur une étape spécifique ne prouve pas que le parc de Mac est sous-dimensionné.

Plusieurs tâches se disputent le même nœud

Si plusieurs builds progressent lentement sur un Mac occupé, il faut comparer leur durée avec celle d’une exécution isolée. Les tâches peuvent se concurrencer sur le processeur, la mémoire, le stockage temporaire, DerivedData ou le simulateur. La conclusion doit reposer sur les journaux de phase et non sur une lecture ponctuelle de l’activité système.

Le simulateur devient le point de blocage

Le lancement d’un simulateur, l’installation de l’application et l’exécution des tests doivent être identifiés comme des événements propres. La documentation Apple sur l’exécution sur appareils simulés ou physiques aide à distinguer la construction de l’exécution. Un test qui attend un appareil ou une session précédente ne doit pas être classé comme une compilation lente.

La signature ou la publication retarde la livraison

Les certificats, profils, trousseaux et identités de signature appartiennent à un domaine différent de la capacité de compilation. La documentation sur la création de code signé pour la distribution rappelle que la signature est une étape contrôlée, avec ses propres prérequis.

Un nœud de production chargé des secrets de distribution devrait être évalué séparément d’un nœud de validation de pull request. Augmenter le nombre de Mac généralistes ne résout pas nécessairement une identité absente, un trousseau verrouillé ou une autorisation de publication manquante. Pour les équipes qui étudient la séparation entre nœuds de signature et nœuds de build, l’objectif doit être la traçabilité et l’isolation, pas seulement le débit.

[ SECTION_05 ] La décision d’extension doit suivre des conditions observables

La capacité doit être dimensionnée à partir de variables mesurées : concurrence de pointe, durée moyenne et durée haute d’un build, attente acceptable, nombre de nœuds fixes, réserve nécessaire et exigences de reprise. Aucun de ces éléments ne doit être remplacé par un nombre de développeurs ou par la capacité théorique d’un Mac.

Décision conditionnelle

• Si la tâche reste dans la file sans runner éligible, corrigez les étiquettes, les groupes, les autorisations ou les dépendances de workflow avant d’acheter une machine.
• Si le runner accepte la tâche mais qu’une dépendance reste bloquée, optimisez le réseau, le registre, l’authentification ou la stratégie de cache.
• Si xcodebuild, les tests ou le simulateur présentent une étape anormalement longue sur un nœud sain, optimisez le projet, l’environnement et la concurrence locale.
• Si la signature bloque alors que la compilation est terminée, isolez le nœud de signature et vérifiez le trousseau, les certificats, les profils et les permissions.
• Si les nœuds sains restent durablement occupés, que la file augmente avec la concurrence et que la durée individuelle reste cohérente, ajoutez de la capacité fixe ou partagée.
• Si la charge se concentre sur une fenêtre de publication, un pilote ou une hausse temporaire, testez une capacité Mac distante à la demande avant de modifier le parc permanent.
• Si la production exige une interface physique, un accès local permanent ou un contrôle matériel spécifique, privilégiez un Mac détenu et administré sur site.

Le mécanisme de concurrence du système d’automatisation doit également être vérifié. La documentation officielle sur les groupes de concurrence montre pourquoi des exécutions peuvent s’annuler, se remplacer ou attendre selon leur configuration. Une file apparente peut donc provenir d’une politique de workflow plutôt que d’un manque de ressources.

[ SECTION_06 ] L’extension doit être validée par un test de bout en bout

Une nouvelle machine n’est acceptée qu’après un parcours réel. Le test doit utiliser une pipeline représentative, et non une simple commande de connexion.

La procédure recommandée est la suivante :

1. Enregistrer l’état initial du workflow, du runner, des étiquettes et des permissions.
2. Ajouter le nœud avec une identité clairement identifiable.
3. Exécuter une tâche de compilation sans signature de distribution.
4. Vérifier les téléchargements, le cache et les dépendances privées.
5. Exécuter les tests sur le simulateur prévu.
6. Rejouer une tâche de signature dans le périmètre autorisé.
7. Contrôler la publication de l’artefact et la conservation des journaux.
8. Redémarrer le nœud, puis vérifier sa reconnexion et sa capacité à accepter une nouvelle tâche.
9. Comparer la chronologie avant et après l’ajout.
10. Retirer le nœud de test si le gain n’est pas démontré par les étapes concernées.

Le redémarrage est essentiel. Une machine qui fonctionne uniquement après une intervention manuelle ne constitue pas une capacité opérationnelle fiable. De même, une amélioration de la file sans amélioration de la phase de compilation peut masquer un second goulot d’étranglement.

[ SECTION_07 ] Comparaison des options après le diagnostic

Le choix ne porte pas seulement sur la vitesse. Il concerne aussi la sécurité des secrets, l’administration, la reprise après incident, la durée d’utilisation et le risque de surprovisionnement.

Option	À retenir si…	Risque principal	Score de pertinence
Mac fixe dédié	la charge est régulière et prévisible	capacité inutilisée hors période de pointe	Élevé pour une charge stable
Pool Mac partagé	plusieurs équipes ont des besoins compatibles	concurrence entre tâches et isolation à renforcer	Élevé si le routage est maîtrisé
Nœud de signature séparé	les certificats et publications exigent un périmètre contrôlé	administration et supervision supplémentaires	Très élevé pour la production
Mac distant loué	la demande est temporaire, variable ou en phase de validation	dépendance à la connectivité et au fournisseur	Élevé pour un pilote ou un pic
Agrandissement immédiat sans preuve	le délai est seulement observé au niveau global	coût sans correction de la cause	Faible

Dans ce dernier cas, une plateforme comme NOVAKVM peut servir à tester une capacité Mac distante sur une vraie pipeline. La comparaison doit porter sur la file, la prise en charge du runner, la préparation, xcodebuild, la signature et la reprise après redémarrage, et non sur la seule disponibilité d’une session distante.

Le Mac acheté reste préférable lorsque la charge est permanente, que l’entreprise doit contrôler physiquement le matériel ou que les exigences de sécurité imposent une présence locale. En revanche, une infrastructure fixe devient moins souple lorsque la demande varie fortement, lorsqu’un lancement mobilise temporairement plusieurs builds ou lorsqu’une équipe veut valider une architecture avant un engagement long.

[ SECTION_08 ] Questions fréquentes des responsables CI

Par quoi commencer lorsque le build CI iOS dépasse le délai ?

Commencez par reconstruire la chronologie complète : entrée dans la file, prise en charge par le Mac Runner, récupération du code et des dépendances, exécution de xcodebuild, tests, signature et publication. Comparez les journaux de l’orchestrateur et du nœud. Sans cette séparation, un délai réseau ou une attente de dépendance peut être attribué à tort au Mac.

Pourquoi un Mac Runner disponible peut-il laisser une pipeline en attente ?

Un nœud peut sembler libre tout en étant inutilisable pour la tâche : étiquette absente, groupe non autorisé, prérequis d’outil incompatible, limite de concurrence ou dépendance de workflow encore bloquée. Vérifiez donc les critères de routage et l’état réellement observé par l’orchestrateur, plutôt que l’activité apparente du bureau distant.

Comment distinguer un build iOS lent d’une capacité Mac insuffisante ?

Un build lent présente une étape anormalement longue même lorsque le nœud est disponible, par exemple la compilation, le test ou la signature. Une capacité insuffisante se manifeste plutôt par des nœuds sains occupés, une file qui augmente avec la concurrence et une durée d’exécution individuelle relativement stable. Il faut comparer ces trois signaux sur plusieurs exécutions.

Faut-il ajouter un nœud Mac lorsqu’un build Xcode dépasse le délai ?

Pas automatiquement. Commencez par vérifier xcodebuild, DerivedData, le simulateur, le trousseau, les certificats et les téléchargements de dépendances. Ajoutez de la capacité seulement si les tâches sont correctement routées, que les nœuds sains restent durablement occupés et que l’attente augmente sans anomalie comparable dans la durée d’un build individuel.

Quelles preuves indiquent qu’une entreprise manque de machines de build Mac ?

Les preuves les plus solides sont une file persistante, des nœuds sains proches de leur limite d’occupation, une attente qui augmente avec la concurrence et des durées de build individuelles cohérentes. Ajoutez la capacité de réserve, les tâches de signature et les fenêtres de publication. Un Mac éteint, mal étiqueté ou inaccessible ne constitue pas une preuve de sous-dimensionnement.

La prochaine étape consiste à remplir une fiche de capacité avec une exécution réelle : chaque phase, chaque attente, chaque reprise et chaque erreur doit y être reliée à un journal. Après cette mesure, un essai de location Mac avec NOVAKVM peut fournir une comparaison concrète entre le pool actuel et une capacité temporaire. Les défauts d’un parc fixe — achat anticipé, capacité inutilisée et maintenance à la charge de l’entreprise — doivent être comparés aux contraintes d’un service distant, notamment la connectivité et les exigences d’accès. Cette vérification permet de choisir une extension courte pour un pic, ou une architecture permanente lorsque les preuves justifient réellement l’investissement.