2026 CI Mac cloud : cold start versus nœuds warm, backoff de file, affinité DerivedData et baselines résidentes configurables
Les équipes plateforme maîtrisent déjà GitHub Actions YAML, pourtant les pipelines iOS semblent flaky quand le premier build est lent, le second rapide et le troisième replonge. Rarement Xcode seul est en cause : misses de cache cold et partage incontrôlé d une racine DerivedData entre jobs parallèles. Cet article vise les équipes qui traitent le Mac cloud comme un VPS en 2026 : quatre points de friction, une matrice cold warm résident, paramètres d affinité et de backoff, trois métriques pour la finance, un déploiement en cinq étapes et FAQ, en complément du guide de routage elastic pool.
Contenu
1. Points de friction : variance, affinité absente, backoff absent, tableaux aveugles
Lorsque vous accrochez un nœud Mac cloud à la CI, vous importez la mémoire musculaire d un VPS Linux : SSH, launchd, disques et sorties vous appartiennent. Les gros modules Swift punissent pourtant la localité NVMe. Si tous les runners partagent encore un arbre DerivedData unique, la variance cold start se déguise en mystérieuse régression du compilateur.
- Queue de latence cold start : le premier checkout paie la résolution des dépendances, le préchauffage d index et les phases de liaison. La finance voit des pics de minutes et suppose un code plus lourd alors que le moteur est le taux de miss du cache.
- Trous d affinité : deux builds consécutifs de la même branche sur des volumes physiques différents perdent le gain incrémental. Les équipes accusent la toolchain alors que la dérive de chemins est la cause.
- Trous de backoff : plusieurs archives sans max parallel ni espacement exponentiel saturent la profondeur de file NVMe ; les échecs ressemblent à des timeouts de liaison flaky au lieu d une contention d infrastructure.
- Observabilité CPU seule : la CI macOS est souvent IO-first. Ignorer l espace libre et les histogrammes de liaison laisse chaque revue bloquée sur ajouter des cœurs.
La matrice suivante complète l article sur pools élastiques hébergés versus routage de baseline dédiée : là vous décidez quels jobs vont sur les minutes macOS hébergées versus les labels bare metal ; ici vous décidez comment découper le Mac cloud une fois les labels posés. Lisez en parallèle pool élastique et routage baseline Mac et matrice capacité et facturation des pools Mac.
2. Matrice de décision : pools cold, hôtes warm, baselines résidentes
| Dimension | Cold d abord (bursts courts) | Warm (caches semi-résidents) | Baseline résidente (slots dédiés) |
|---|---|---|---|
| Charge typique | lint, tests unitaires, matrices de compilation légères | PR incrémentales multi-modules moyennes | archives, notarisation, longues matrices UI |
| Sensibilité de queue | minutes échangées contre élasticité | P95 stable avec migration occasionnelle | variance de liaison très basse requise |
| Stratégie disque | sous-répertoires par job plus GC nocturne | chemins sticky ou snapshots dorés courts | double partition build versus artefacts |
| Stratégie de file | parallélisme élevé avec plafonds de retry stricts | parallélisme moyen avec seuils de profondeur | parallélisme bas avec fenêtres de changement |
3. Affinité DerivedData et barrières anti-stampede
L affinité n exige pas une adhérence éternelle à une même machine : il faut des caches de modules statistiquement réutilisables. En pratique : un DERIVED_DATA_PATH par slot de parallélisme, isoler les archives des builds incrémentaux, bloquer les nouvelles archives quand l espace libre tombe vers quinze pour cent.
export DERIVED_DATA_PATH=/Volumes/ci/d12/$JOB_SLOT/dd
export COCOAPODS_CACHE_PATH=/Volumes/ci/d12/$JOB_SLOT/cocoapods
xcodebuild -scheme App -destination 'platform=iOS Simulator,name=iPhone 16' build
Alignez le backoff sur les politiques de retry d entreprise : des plafonds plus bas et des espacements plus larges sur les échecs de liaison évitent les thundering herds sur disques rouges, tandis que les échecs de compilation doivent échouer vite pour libérer des slots.
Les retries de liaison sont un budget, pas un bouton de récupération gratuit. Chaque retry rivalise avec les jobs frais pour la même bande passante NVMe. Élargir les fenêtres sans baisser la parallélité déplace la douleur vers l astreinte. Pattern pragmatique : les PR incrémentales peuvent répéter quelques compilations à court intervalle quand le cache touche ; les pipelines d archive doivent plafonner les retries de liaison à une ou deux tentatives avec pauses exponentielles pour éviter des tempêtes de liens parallèles.
La sémantique warm sur un seul hôte exige un runbook de migration : même le bare metal remplace du matériel ou migre des volumes. Documentez quels répertoires peuvent être effacés entièrement et lesquels reviennent d un snapshot doré : langage commun avec le fournisseur et garde-fou contre les régressions silencieuses quand l identifiant machine change mais le CPU reste vert.
4. Cinq étapes de déploiement du profilage à la vérification
- Profiler les jobs : découper les pipelines en cold, warm et baseline ; mesurer parts file, compilation, liaison et upload. Si la part liaison monte, inspecter la contention DerivedData avant d acheter du CPU.
- Contrat de chemins : documenter JOB_SLOT ou label self-hosted vers répertoires ; interdire aux branches expérimentales d écrire dans une racine de cache partagée.
- Gardes de parallélisme : max parallel global pour archives entre un et deux ; PR incrémentales plus hautes mais liées à des courbes de backoff.
- Câblage d alertes : alimenter marge disque, profondeur de file et part des minutes de retry dans la même histoire d observabilité que observabilité CI Mac cloud pour surfacer avant les flakes visibles.
- Vérification triple build : reconstruire trois fois le même commit, comparer P95 et clusters d échecs. Si la variance reste, planifier un second hôte baseline avant d augmenter la parallélité.
5. Trois signaux citables : file, queue de liaison, marge disque
- Part de file dans le temps de bout en bout : au-delà d environ quinze pour cent en corrélation avec le rythme de commit, cela indique un mélange de pool, pas un manque de GHz.
- Écart P95 de liaison : trois builds identiques dont les queues de liaison diffèrent de plus d environ vingt-cinq pour cent exigent un audit des racines DerivedData partagées et de la marge disque.
- Part des minutes de retry : au-delà d environ un quart du total, backoff manquant ou barrières trop larges : baisser la parallélité avant de scaler horizontalement.
6. Couplage avec le routage élastique
Si les PR vont déjà vers l élasticité hébergée et les nightlies vers des baselines Mac, cet article complète la couche interne : le cold absorbe les pics de minutes, le warm stabilise la sensation incrémentale, les baselines rendent les archives prévisibles. Finance et plateforme partagent alors un vocabulaire unique.
6.1 Garde-fous opérationnels pour revues finance et plateforme
Les équipes finance demandent des leviers qui stabilisent les budgets minutes sans tuer la vélocité : les pools cold monétisent la parallélité courte, les nœuds warm et baseline réduisent la variance de liaison et les retries coûteux. Suivez part de file, écart P95 de liaison et minutes de retry pour montrer pourquoi des plafonds de parallélité ciblés battent souvent l achat aveugle de cœurs.
Opérationnalisez ces garde-fous dans YAML et launchd : des labels comme mac-ci-baseline doivent être mariés à des limites de slot documentées, conventions de chemins et seuils d alarme. Ajoutez un runbook d une page décrivant comment l astreinte baisse d abord la parallélité quand la quote de retry monte, puis seulement commande de capacité. Vous évitez l achat réflexe de runners supplémentaires alors que le goulot est une racine DerivedData partagée ou une file NVMe rouge.
Pour les secteurs sensibles, un paragraphe d audit dans le ticket de change sur les données résiduelles sur le builder, la fréquence de purge des artefacts et la rétention des logs renforce indirectement la discipline de séparation des caches et rend les choix warm versus cold traçables plutôt qu une liste de shopping de Macs supplémentaires.
7. FAQ
Un seul Mac peut-il émuler du warm ? Oui avec des slots de répertoire et la profondeur de file, mais des fenêtres de migration subsistent. Les archives doivent rester dans une file dédiée à faible parallélisme.
L affinité entre-t-elle en conflit avec la sécurité ? L isolation multi-locataire bat le sticky aveugle : utilisateurs Unix et montages séparés pour éviter la pollution croisée des secrets et caches.
Faut-il immédiatement un cache distant distribué ? Souvent non : partitionnement NVMe correct et chemins par job réduisent plus tôt la variance que des clusters de cache prématurés.
Comment expliquer le backoff au produit ? Comme assurance contre les pannes corrélées : une courte pause intentionnelle après erreurs de liaison vide plus vite les files NVMe que des retries immédiats agressifs.
Les fermes de simulateurs ? Arbres DerivedData séparés par shard et surveillance de la marge disque : les tests UI amplifient le churn d artefacts même quand la compilation semble modeste.
8. Conclusion et suites
Les cold starts ne sont pas des méchants ; c est la co-planification sans freins. Les hôtes warm et les baselines résidentes transforment la latence de queue d un processus aléatoire en paramètres réglables. Lire honnêtement les courbes de file et de disque rend le Mac cloud programmable plutôt qu un Mac partagé mystérieusement lent.
Les pools hébergés contraignent toujours la disposition et les barrières selon la politique du fournisseur : macOS ne ressemble jamais totalement à un terrain de build possédé. Un empilement purement cold sur un petit disque invite archives et PR à piétiner la même racine DerivedData. Les équipes qui veulent un débit iOS stable tout en gardant les habitudes SSH et launchd des opérations VPS Linux gagnent en général à louer des nœuds Mac cloud Apple Silicon VPSMAC avec baselines à faible parallélisme pour les liaisons lourdes et la variance cold pour les charges légères tolérantes, plutôt qu à marteler des pics sur un cache partagé unique.