En 2026, sur une ferme Mac mini M4 répartie entre régions, le goulot d’étranglement n’est souvent plus le CPU brut : c’est xcodebuild avec le Parallel Testing, la superposition d’instances Simulateur, et la pression APFS du Derived Data plus des runtimes iOS lourds. Cette matrice décisionnelle relie -parallel-testing-enabled, le nombre de destinations et le budget de concurrence Simulateur par nœud aux verrous de build, à la politique de chemins et à une checklist d’acceptation 1 To / 2 To prête à coller dans un runbook d’exploitation.

Scaler la CI Apple sur des Mac mini M4 homogènes dans plusieurs zones réduit la latence, mais deux jobs sur le même arbre dérivé ou quatre destinations « parallèles » peuvent effondrer le temps mural si CoreSimulator saturations mémoire et disque. Traitez le ventilage des destinations (combien de simulateurs une invocation xcodebuild alimente) et le parallélisme au niveau job comme deux budgets indépendants. Croisez avec la matrice Watchman vs Git, FSEvents, throttling et paliers disque 1 To / 2 To pour les mêmes seuils d’hygiène que les tableaux ci-dessous.

Tableau de paramètres : -parallel-testing-enabled, nombre de destinations, concurrence Simulateur

-parallel-testing-enabled YES répartit les cibles sur plusieurs destinations dans une invocation. Sur une grappe parallèle, plafonnez destinations par processus et Simulateurs concurrents par nœud séparément : sans marge, CoreSimulator (RAM, boot, snapshots) plafonne la p95 avant le CPU. Ventilez les schémas sur plusieurs Mac plutôt que d’empiler les destinations.

-parallel-testing-enabled Nombre de destinations (par processus, ordre de grandeur) Budget de concurrence Simulateur (par nœud)
NO (file unique par défaut) 1 (-destination cible unique) 1–2 appareils actifs ; gardez les tests UI à 1 sur hôtes partagés pour la stabilité.
YES, surtout tests unitaires 2–3 (même SDK / famille de runtime compatible) 2–3 boots décalés ; plafonnez aussi les jobs concurrents pour que les totaux ne se multiplient pas à l’aveugle.
YES, suites UI / snapshots mélangées ≤2 (scalez d’abord le parallélisme inter-nœuds avant d’augmenter les destinations) 2 fixes + alertes pression mémoire ; les runs inter-régions privilégient la reproductibilité au pic de fan-out.
Indice d’acceptation : mesurez la p95 des tests en balayant 1→4 destinations sur un M4 de préprod ; le coude où la p95 stagne fixe le plafond par processus.

Si une étape touche une base partagée sur volume partagé, alignez les écrivains avec la matrice SQLite WAL et single-writer sur volume partagé afin que le Parallel Testing ne masque pas une tempête de checkpoints WAL.

Verrous de build

Des xcodebuild concurrents sur le même Derived Data ou produits corrompent les caches et génèrent des « symboles manquants » intermittents. Un verrou de build garantit un seul écrivain dans la fenêtre de publication, même avec une CI distribuée.

Planificateur (ex. une allocation « promote » sous Nomad) et flock court s’additionnent : l’un évite deux publieurs planifiés ; l’autre évite qu’un script ou rsync coupe une écriture. Même schéma que Nomad, affinité batch, verrous de build et matrice disque 1 To / 2 To — adaptez l’outil, gardez la sémantique.

LOCK_FILE="/var/tmp/xcode-derived-publish.lock"
flock -n "$LOCK_FILE" bash -c '
  xcodebuild -scheme "$SCHEME" -parallel-testing-enabled YES test
  rsync -a "$LOCAL_DERIVED/Build/Products/" "/Volumes/CIArtifacts/$BUILD_ID/"
' || { echo "lock busy"; exit 17; }

Gardez la compilation et l’essentiel du travail Derived Data en dehors du verrou ; à l’intérieur : signature, renommage atomique et mise à jour de l’arbre canonique seulement. Évitez SSHFS pour les arbres verrouillés : préférez des volumes APFS locaux ou des systèmes réseau dont la sémantique de verrouillage est documentée.

Chemins Derived Data

Sur hôte CI partagé, le Derived Data par défaut devient conflictuel sans sous-arbre par job. Utilisez -derivedDataPath scopé par job (clé pipeline) pour éviter tout index modifiable partagé, puis archivez ou rsync uniquement les produits utiles.

  • Variables CI : dérivez le chemin d’identifiants de job immuables ; purgez agressivement les espaces de travail en échec et appliquez une politique de rétention sur les artefacts réussis.
  • Données Simulateur : traitez CoreSimulator et les répertoires de runtimes comme des métriques de première classe — ils grossissent à chaque bump Xcode indépendamment de la taille du dépôt.
  • Cache lecture partagé (optionnel) : montez des caches de dépendances en lecture seule ; n’autorisez jamais deux écrivains à « optimiser » le même cache mutable sans la même discipline flock que pour les binaires de production.

En promotion inter-régions, le Derived Data compile peut rester local ; documentez le chemin de référence pour déboguer un build rouge.

Seuils de nettoyage disque

Le Parallel Testing gonfle vite artefacts, crash logs et données simulateur. Des bandes d’utilisation (mêmes pourcentages sur 1 To et 2 To) servent de rails : 2 To retarde la crise, pas les runtimes multiples.

Bande d’utilisation Ligne 1 To : action Ligne 2 To : action
Jusqu’à ~70 % Automatiser xcrun simctl delete unavailable, tailler les anciennes générations Derived Data, balayer les répertoires temp CI chaque semaine. Même cadence — la marge n’est pas une excuse pour reporter l’hygiène.
70–80 % (jaune) Prévoir extension ou déport d’archives ce sprint ; baisser les plafonds de destinations -parallel-testing-enabled et les jobs concurrents. Le jaune arrive souvent tard ; réduisez la concurrence Simulateur et le fan-in de jobs avant de remonter les destinations.
80–90 % Figer les suites UI lourdes et les clean builds complets ; réduire les charges rsync d’artefacts jusqu’à rétablir de la marge. Évincer d’abord les runtimes inutilisés — les grappes 2 To masquent souvent l’embonpoint des runtimes jusqu’au précipice.
Au-delà de ~90 % (rouge) Ne plus admettre de nouveau fan-out de tests ; drainer ou remplacer le stockage ; auditer instantanés APFS et volumes « invisibles » ; afficher le niveau disque en continu sur les tableaux de bord.
70 %
Ligne d’automatisation courante : le nettoyage planifié doit tourner sans héroïsme.
80 %
Jaune : revoir le parallélisme ou provisionner du disque ce sprint.
90 %
Rouge : stopper la charge nouvelle ; ajouter des nœuds ou monter de tier avant que la CI devienne gestion d’incident.

Checklist d’acceptation (extrait) : df hebdo + empreinte Simulateur ; pas de collision -derivedDataPath ; plafonds Parallel Testing versionnés ; jaune = ticket avec owner ; rouge = revue capacité. Pour l’achat, les pages tarifs / achat restent lisibles sans compte.

FAQ

Plus de destinations n’a pas accéléré les tests. Le Simulateur, la mémoire ou le disque est saturé : ventilez le schéma sur plusieurs nœuds ou baissez la concurrence Simulateur par hôte avant de remonter encore les destinations.

Pic de flock « busy ». La section critique est trop large ; réduisez-la à la signature et à la publication finale.

Les nœuds 2 To passent vite au jaune. Souvent plusieurs betas Xcode et runtimes accumulés — gardez les mêmes seuils en pourcentage mais une politique de retrait des runtimes plus stricte.

Guide opérationnel uniquement. Les drapeaux CLI et le comportement du Simulateur évoluent avec macOS et Xcode. Traitez les chiffres comme des heuristiques : validez en préproduction, documentez les politiques de suppression et ajustez les sondes selon rétention et contraintes de conformité.
Capacité Mac parallèle

Ajoutez des Mac mini M4 homogènes avant que le Parallel Testing pousse le disque au rouge

Parcourez les pages publiques tarifs et achat — sans connexion pour comparer ; payez lorsque le mix capacité / régions et les tiers 1 To / 2 To correspondent à votre matrice Parallel Testing et Simulateur.

Louer / commander Mac mini M4 Voir les tarifs (sans connexion)