La planification de capacité de build sur Mac mini M4 ne se calcule pas avec le nombre de développeurs : elle exige quatre mesures de pointe, une capacité utile par nœud et une marge de redondance. Pour un essai non critique, commencez par un nœud et mesurez ; pour une chaîne de production, partez d’une capacité de base séparée d’un nœud de reprise ou d’une capacité distante.
Cet article s’adresse aux responsables IT qui budgètent l’infrastructure d’une nouvelle équipe iOS, aux responsables de l’efficacité qui voient les files ralentir les validations, ainsi qu’aux CTO et directeurs techniques qui arbitrent entre machines fixes, location distante et architecture hybride.
[ SECTION_01 ] Les quatre mesures d’entrée
Avant de chercher combien de Mac mini M4 sont nécessaires, l’équipe doit remplir cette fiche. Une valeur mensuelle moyenne masque presque toujours les embouteillages de fin de sprint, de fusion ou de publication.
| Mesure | Source attendue | Variable de calcul | Seuil de décision |
|---|---|---|---|
| Tâches arrivant en pointe | Journaux CI sur les créneaux chargés | Charge entrante par période | Reproduire la période la plus tendue |
| Durée P95 par type de tâche | Historique des jobs et mesures répétées | Temps réel consommé par tâche | Ne pas remplacer le P95 par une moyenne |
| Délai d’attente visé | SLA interne de validation et de publication | File acceptable avant exécution | Déclencher l’extension si le délai est dépassé régulièrement |
| Interruption tolérée | Criticité du pipeline et plan de reprise | Nœuds de réserve nécessaires | Séparer la réserve de la capacité courante |
Le P95 signifie ici que la capacité doit absorber les exécutions lentes mais habituelles, plutôt que de reposer sur un cas idéal. Les quatre entrées doivent être associées à une fenêtre précise : heure de la journée, type de branche, état du cache et version de Xcode.
Rappel de méthode : une pointe de processeur ne prouve pas qu’un nœud manque. Si la file provient d’un script sérialisé, d’une dépendance téléchargée à répétition ou d’un cache inutilisable, l’achat d’une machine supplémentaire ne traite pas la cause.
[ SECTION_02 ] Intensité des charges CI/CD iOS
Un pipeline iOS n’est pas une tâche unique. Le contrôle du code, les tests unitaires, les tests d’interface, l’archive et la signature n’ont ni la même durée ni le même profil de concurrence. Une moyenne globale peut donc sous-estimer la charge des archives tout en surestimant celle des validations rapides.
Les journaux doivent être regroupés par famille :
- contrôles et compilation de vérification sur chaque demande de fusion ;
- tests unitaires exécutés fréquemment ;
- tests d’interface, souvent plus sensibles aux simulateurs et aux ressources partagées ;
- archives destinées à la distribution ;
- tâches de signature et de publication, moins nombreuses mais plus sensibles au délai ;
- tâches planifiées qui se superposent aux demandes interactives.
Pour chaque famille, relevez le nombre de tâches pendant la période la plus chargée et sa durée P95. La charge de la fenêtre s’écrit ainsi :
Charge de pointe = somme(nombre de tâches par famille × durée P95 de la famille)
Cette formule ne donne pas encore le nombre final de machines. Elle mesure seulement le travail demandé. Il faut ensuite connaître la production réellement obtenue par un nœud dans les mêmes conditions.
Les tâches planifiées doivent être ajoutées à la charge lorsqu’elles occupent les mêmes créneaux que les validations. Une publication déclenchée manuellement doit également être comptée si son SLA est garanti. À l’inverse, une tâche nocturne peut rester dans une capacité séparée lorsque son délai est volontairement plus souple.
La documentation officielle sur les phases de build d’une cible Xcode aide à isoler compilation, scripts et ressources copiées. Cette distinction est importante : un script lent ne doit pas être attribué automatiquement au manque de puissance du Mac.
[ SECTION_03 ] Capacité utile d’un nœud
La fiche technique délimite les configurations possibles, mais elle ne transforme pas un nombre de cœurs en builds par heure. La fiche technique officielle du Mac mini peut confirmer les variantes matérielles disponibles ; elle ne connaît ni la taille du projet, ni les dépendances, ni les scripts de l’équipe.
Le benchmark doit utiliser :
- le même commit ou une version de code explicitement identifiée ;
- la même version de Xcode et le même SDK ;
- les mêmes dépendances et la même source de téléchargement ;
- un état de cache documenté ;
- le même schéma et les mêmes options de build ;
- le même mode de signature lorsque l’archive est mesurée.
Exécutez séparément un build froid, un build incrémental, une série de tests et une archive. Répétez chaque scénario suffisamment longtemps pour observer les variations, puis conservez le P95 de chaque résultat. Le nombre de répétitions doit être indiqué dans le rapport interne ; il ne faut pas présenter une mesure isolée comme une performance générale.
Le résumé de chronométrage de Xcode permet d’identifier les dépendances lentes et les étapes sérialisées. La méthode est décrite dans la documentation consacrée à l’amélioration de la vitesse des builds incrémentaux. Les réglages de schéma et les dépendances de cibles doivent aussi être vérifiés à partir des options de construction des schémas Xcode.
La capacité utile s’exprime alors comme suit :
Capacité utile d’un nœud = minutes disponibles dans la fenêtre × taux de production mesuré
Le taux de production n’est pas une propriété universelle du M4 ou du M4 Pro. Il dépend du projet et du scénario. Une archive lourde peut avoir un résultat très différent d’une compilation incrémentale. Il faut donc conserver plusieurs capacités, au lieu de fabriquer un unique chiffre moyen.
[ SECTION_04 ] File d’attente et seuil d’extension
Le modèle de base est volontairement simple :
Nœuds de base = plafond(charge de pointe ÷ capacité utile d’un nœud)
Le résultat est toujours arrondi à l’entier supérieur. Ensuite, l’équipe vérifie si cette capacité respecte le délai d’attente cible. Si la file reste trop longue, la capacité doit augmenter, même lorsque l’utilisation moyenne paraît acceptable.
Trois niveaux de service conduisent à des décisions différentes :
- Builds nocturnes : une file plus longue peut être acceptable si le résultat est disponible avant le début de journée.
- Validation quotidienne : le délai doit rester compatible avec le cycle de revue ; une file persistante bloque les fusions et pousse les développeurs à relancer manuellement les jobs.
- Publication : l’archive et la signature exigent une capacité réservée ou une reprise clairement testée. Une simple capacité moyenne n’est pas suffisante.
Le taux d’utilisation doit être observé avec la file et le P95 d’attente. Il n’existe pas de seuil universel valable pour tous les projets. Une ferme peut sembler peu occupée tout en refusant les archives au mauvais moment ; une autre peut afficher une forte utilisation tout en respectant son SLA grâce à des tâches courtes.
Les labels et groupes de runners permettent de diriger une classe de tâche vers une capacité compatible, comme le documente la page officielle sur l’attribution des labels aux runners auto-hébergés. Le principe reste valable avec un autre ordonnanceur : séparer les archives, les tests d’interface et les validations évite qu’un flux critique soit noyé par des tâches secondaires.
[ SECTION_05 ] Concurrence et isolation
Lancer plusieurs builds sur le même Mac peut améliorer le débit apparent, mais seulement jusqu’au point où les ressources se disputent. DerivedData, simulateurs, espace disque, trousseaux, certificats et répertoires de travail doivent être examinés séparément.
Le partage d’un répertoire DerivedData peut accélérer certains scénarios, mais il complique le nettoyage et augmente le risque de réutiliser un artefact inadapté. Le partage d’un simulateur peut créer des collisions entre tests. Les éléments de signature, eux, exigent une séparation stricte des accès et des journaux.
Une comparaison utile consiste à mesurer deux configurations :
- un nœud exécutant plusieurs tâches isolées par répertoires, utilisateurs ou conteneurs de travail ;
- plusieurs nœuds exécutant chacun une tâche principale avec nettoyage complet.
La première approche peut réduire le nombre d’hôtes, mais elle concentre les pannes et rend le diagnostic plus difficile. La seconde consomme davantage de capacité fixe, mais limite le domaine d’erreur et simplifie la remise à zéro.
Expérience à formaliser : le nombre de créneaux simultanés doit venir d’un test de pression sur le projet réel. Il ne faut pas reprendre un chiffre trouvé dans une fiche commerciale ou dans un forum, car les dépendances, les scripts et les tests d’interface changent complètement le résultat.
[ SECTION_06 ] Contrôle avant toute commande
La liste suivante transforme le modèle en décision opérationnelle. Chaque point doit être validé dans un document de capacité versionné.
- [ ] Extraire les tâches de la fenêtre de pointe plutôt que la moyenne mensuelle.
- [ ] Séparer contrôles, tests unitaires, tests d’interface, archives et publication.
- [ ] Calculer un P95 de durée pour chaque famille de tâches.
- [ ] Noter la version de Xcode, le commit, le SDK, les dépendances et l’état du cache.
- [ ] Mesurer séparément build froid, build incrémental, tests et archive.
- [ ] Identifier les scripts sérialisés et les dépendances lentes avant d’ajouter un nœud.
- [ ] Tester la concurrence avec les mêmes simulateurs, trousseaux et répertoires de travail.
- [ ] Comparer la file P95 au délai d’attente réellement promis.
- [ ] Exclure les nœuds de réserve du calcul de capacité quotidienne.
- [ ] Tester une panne, une maintenance et une mise à niveau de Xcode.
- [ ] Recalculer la capacité après toute modification majeure du projet ou de l’outil.
- [ ] Conserver les commandes et journaux bruts pour rendre le résultat vérifiable.
Cette procédure répond aussi à la question du choix entre une machine plus puissante et plusieurs nœuds. Si le temps est dominé par une étape sérialisée, une configuration plus rapide peut être pertinente. Si plusieurs tâches indépendantes attendent simultanément, plusieurs nœuds offrent généralement une meilleure isolation du flux, à condition que le test de charge le confirme.
[ SECTION_07 ] FAQ pour la décision d’infrastructure
Combien de Mac mini M4 faut-il à une équipe iOS pour la CI ?
Il n’existe pas de ratio fiable entre développeurs et machines de build. Le calcul doit partir du volume de tâches en pointe, de la durée P95 de chaque type de build, de la capacité mesurée d’un nœud et du délai d’attente acceptable. Un petit pilote peut commencer avec un seul nœud ; une chaîne de production doit ajouter une marge de reprise et de maintenance.
Comment convertir une file d’attente en nombre de nœuds Mac ?
Mesurez les tâches arrivant pendant la période de pointe, puis additionnez leur durée P95 afin d’obtenir une charge en minutes-machine. Divisez cette charge par la capacité utile mesurée d’un nœud sur la même période. Ajoutez ensuite la marge nécessaire pour respecter le délai d’attente cible, arrondissez toujours à l’entier supérieur et vérifiez le résultat avec un test de charge.
Un Mac mini M4 peut-il exécuter plusieurs builds Xcode simultanément ?
La possibilité technique ne garantit pas une capacité proportionnelle. Les compilations, tests, simulateurs, DerivedData, scripts, trousseaux et certificats peuvent se disputer les mêmes ressources. Le nombre acceptable de tâches simultanées doit donc être mesuré avec le projet réel, le même état de cache et les mêmes dépendances. Sans ce test, il vaut mieux considérer la concurrence comme une hypothèse.
Pour la CI iOS, faut-il choisir une machine plus puissante ou plusieurs nœuds ?
Une machine plus puissante peut réduire la durée d’une tâche, mais plusieurs nœuds améliorent souvent la capacité parallèle et limitent le domaine d’une panne. Le choix dépend de la part de travail sérialisée, du profil des archives, de la simultanéité des demandes et du délai de publication. Comparez le débit utile par coût total, et non la seule fiche technique.
À quel niveau d’utilisation faut-il agrandir une ferme de builds Mac ?
L’utilisation moyenne ne suffit pas comme seuil. Une équipe doit déclencher une étude d’extension lorsque le délai P95 d’attente dépasse régulièrement son objectif, notamment pendant les validations de fusion ou les publications. Une pointe CPU isolée ne justifie pas l’achat d’un nœud. La décision doit combiner file d’attente, durée P95, erreurs, maintenance planifiée et capacité de reprise.
[ SECTION_08 ] Arbitrage de capacité et de coût
Le coût pertinent ne se limite pas au prix d’un Mac. Il comprend l’acquisition ou la location, l’espace d’hébergement, le remplacement, l’administration, la surveillance, le stockage, le temps de récupération après panne et la perte de productivité liée à l’attente.
| Architecture | Capacité principale | Point fort | Limite à vérifier | Choix indiqué |
|---|---|---|---|---|
| Nœud unique | Un seul flux ou faible concurrence | Pilote simple et peu de coordination | Panne totale et file immédiate | Essai non critique |
| Pool fixe | Plusieurs nœuds disponibles en permanence | Débit prévisible et isolation améliorée | Capacité inutilisée hors pointe, maintenance à organiser | Flux quotidien stable |
| Pool fixe avec Mac distant élastique | Socle permanent plus renfort ponctuel | Absorption des publications et pics courts | Délais d’accès, sécurité et coût variable à mesurer | SLA critique ou charge irrégulière |
Le coût de l’attente doit être calculé à partir du temps réellement perdu par les développeurs, et non d’une estimation abstraite. Une équipe peut comparer :
Coût total = capacité fixe + capacité élastique + exploitation + perte liée à l’attente
Une capacité distante n’est pas automatiquement moins chère. Elle devient intéressante lorsque les pics sont courts, lorsque l’achat laisserait des machines inutilisées, ou lorsque l’équipe doit tester une charge avant un engagement matériel. À l’inverse, une charge stable et continue peut justifier un pool fixe, si l’organisation accepte la maintenance et le remplacement.
Pour un pilote, une seule machine distante permet de jouer le même benchmark sans engager immédiatement un parc. La page Mac mini M4 distant de NOVAKVM peut servir de point de départ pour vérifier l’accès, le mode d’administration et la compatibilité du projet. Les résultats du benchmark doivent ensuite être replacés dans la formule de capacité, sans reprendre une performance non mesurée.
[ SECTION_09 ] Choix selon le niveau de criticité
Une chaîne non critique peut commencer avec un nœud unique, à condition que les développeurs sachent qu’une panne ou une maintenance peut retarder le résultat. Le pilote doit produire des mesures exploitables, pas seulement confirmer que Xcode démarre.
Pour une chaîne quotidienne, le socle doit couvrir la charge P95 observée. La réserve doit rester séparée du calcul d’utilisation courante. Elle doit être testée avec une vraie tâche d’archive ou de validation, puis documentée dans le plan de reprise.
Pour une publication critique, le calcul doit intégrer la simultanéité des archives, la signature, la maintenance planifiée et la perte d’un hôte. Un pool fixe accompagné d’une capacité distante à la demande peut éviter de dimensionner tout le parc sur quelques fenêtres de forte activité. La décision finale dépend du SLA, du niveau d’isolation exigé et du coût d’une attente de publication.
L’accès aux Mac distants de NOVAKVM permet de prolonger ce test avec une machine séparée du poste local. L’objectif n’est pas de choisir un nombre théorique, mais d’obtenir une capacité mesurée avec le code, Xcode, les dépendances et les règles de signature de l’entreprise.
Le modèle devient fiable lorsque chaque nombre possède une source : journal CI, commande de benchmark, rapport de chronométrage, test de pression ou décision SLA. Sans cette traçabilité, « trois machines » ou « six machines » ne sont que des hypothèses difficiles à défendre devant les achats et la direction technique.
Un achat fixe impose un investissement initial, une capacité parfois inactive, une maintenance matérielle et un domaine de panne à gérer sur site. Il devient moins adapté lorsque les publications sont saisonnières ou que l’équipe doit absorber rapidement une nouvelle charge. La location de Mac distant ajoute, elle, une dépendance réseau, une vérification des accès et un contrôle attentif de l’isolation ; en contrepartie, elle évite de figer immédiatement tout le budget dans des hôtes qui ne seront pas toujours sollicités. Pour une charge variable, louer auprès de NOVAKVM un Mac de référence afin d’exécuter le benchmark constitue une étape plus sûre que de commander un parc sur la seule base du nombre de développeurs. Consultez la disponibilité d’un Mac mini M4 chez NOVAKVM après avoir défini les mesures, le SLA et les exigences de sécurité.