Les équipes plateforme exécutent déjà GitHub Actions, GitLab Runner ou Jenkins pour les builds macOS, mais peinent encore à uniformiser les files d’attente, à mutualiser une vision des coûts entre dépôts et à piloter des machines dédiées comme des VPS accessibles SSH. Ce guide s’adresse aux équipes qui basculent l’exécution iOS/macOS sur des Mac distants dédiés : sept hypothèses silencieuses qui font échouer un déploiement Buildkite, une grille de décision Elastic CI comparée sous quatre axes, un runbook passation en six étapes (installation, jeton, tags, hooks, santé, parallélisme), plus des renvois vers nos articles sur le runner GitHub Actions, le GitLab Runner et l’agent SSH Jenkins.
La couche contrôle Buildkite met bien en évidence les files et les permissions, mais macOS demeure Xcode + trousseau + amplification écriture disque. Ces sept points convertissent « on branche un agent » en accord d’exploitation chiffrable, alignés sur nos guides builds reproductibles et gouvernance SwiftPM/Pods / volumes DerivedData.
Confondre CI élastique et concurrence illimitée : l’élasticité décide si la machine prend du travail, pas si elle survit simultanément à plusieurs pics mémoire xcodebuild ou à la lutte NVMe — imposez des plafonds de parallélisme.
Ignorer les règles de files et tags : Buildkite roule les jobs par tags ; tout ce qui surcharge un tag (gros CocoaPods contre smokes légers) provoque contention — retrouvez l’approche profilage de notre guide runner.
Traiter les hooks comme scripts « quelconques » : injection d’environnement, masquage secrets et nettoyage doivent vivre dans des hooks explicites côté utilisateur agent — pas dans des profils interactifs.
Plusieurs processus buildkite-agent sous le même utilisateur : un DerivedData par défaut partagé facilite les builds erratifs — séparez les comptes ou imposez segmenter BUILDKITE_BUILD_PATH.
Tester seulement que git clone fonctionne : signer et notariser sans parcours d’adhésion conduit à des ruptures au sprint release — rattachez l’adhésion à une CI de notarisation.
Éparpiller SSH (ports, bastion, IPs) dans le chat informel : ils appartiennent à un unique runbook interne — traçabilité et audit inclus.
Absence de règle « seuil libre ≤ X → suspendre scheduling » : faire monter une file alors que la marge libre tombe trop bas rend l’état Git/Xcode incomplet ; c’est toujours plus cher qu’un buffer de file courte — même logique que les Pools de builds entreprise.
Au fond, vous traitez un « remote Mac » comme processeur générique alors qu’il faut le voir comme nœud porteur d’empreintes Xcode et de périmètres trousseau. Buildkite clarifie qui prend quoi dans la file ; vos équipes plateforme doivent néanmoins fournir contrats disque, plafonds de concurrence et SLO nettoyage. À côté de Jenkins Buildkite limite Groovy excessif tout en exposant l’environnement réel au bon niveau pour les équipes sensibles VPS.
Si vous côtoyez GitLab, calquez la logique resource_group de notre article GitLab Runner : exprimer des exclusions mutuelles par files/clusters fonctionne encore, tant que vous acceptez une limite physique : « combien de builds xcodebuild peut porter cette machine ».
À chaque projet de quatrième moteur CI, fixez d’abord trois SLA : P95 files, débogabilité des erreurs, coût de rotation secret. Si GitHub/GitLab possèdent déjà vos évènements tout en masquant vos files et vos coûts transversaux, Buildkite cible peut-être mieux votre goulot sans script supplémentaire.
Pas de palliatif miracle : vous décidez où vivent vos pipelines, qui possède files et IAM, si les runners macOS restent dédiés sur le long terme. Le tableau ci-dessous cadre les séances d’archi et coupe les querelles logos.
| Axe | Buildkite + agent | GitHub Actions auto-hébergé | GitLab Runner (shell) | Agent SSH Jenkins |
|---|---|---|---|---|
| Plan de contrôle | API/UI Buildkite ; pipeline.yml déclarant les étapes | YAML workflow couplée aux événements PR | Projets/MR GitLab + .gitlab-ci.yml | Pilotes Jenkins et Job DSL — souple mais exposé au drift |
| Élasticité | Agents élastiques / routage files ; tags | Inscription runner + concurrence auto-gérée | Concurrence runner + schémas resource_group | Labels + plugins de limitation — matures, verbeux |
| Secrets & audit | Secrets Buildkite + hooks ; rotation maison | GitHub Secrets + OIDC éprouvé | Variables CI/CD masquées/protégées | Domaine identité lié au blast ray du contrôleur |
| Cas pertinent | Files multi-dépôts, Mac SSH prioritairement | Flux centrés Pull Request GitHub | Pipeline MR centrée GitLab | Artefacts on-prem validations, SCM mixtes |
« Louer un Mac façon VPS » signifie côté Buildkite acheter un profil d’agent routable : SSH prévisible, gammes SSD planifiables et tags portant vos empreintes Xcode.
Teams tournés GitHub qui partagent un petit équipement macOS entre lignes métier privilégient souvent les checks PR sous Actions et confient archives volumineuses, notarisation, intégration longue aux files Buildkite pointées sur ces mêmes Mac — conservez alors des séparateurs disques / domaines secrets avant que ces deux piles ne mélangent leurs artefacts.
Contrastez également les packs minutes Apple contre notre matrice Xcode Cloud vs Mac distant dédié lorsque vous suivez l’intégration Apple ; cet article présuppose que vous vous assumez votre plan d’exécution macOS.
Si vous passez sous location de nœuds dédiés, employez Buildkite comme vue files + tableau de supervision plutôt que d’épicer des scripts dispersés — puis ancrez vos arbitrages financiers avec TCO achat contre location.
Priorité chronologique : identité dossiers puis installation token enfin stratégie de parallèle — même base SSH que notre liste SSH contre VNC pour éviter l’illusion « ping OK » alors que les compilats clignotent.
Créez un utilisateur CI et une racine de travaux : par exemple /Users/ci/buildkite, SSH clé uniquement, jamais fusionné avec la session utilisateur bureau.
Installez buildkite-agent : installeur officiel ou Homebrew ; vérifiez que la révision fonctionne bien sous launchd.
Écrivez buildkite-agent.cfg : jeton, tags (queue=ios,arch=m4…), et build-path sur NVMe rapide.
Cadrez hooks et environnement : exporter DERIVED_DATA_PATH (ou chemins/build) depuis le hook d’environnement — évitez de dépendre d’un rc shell interactif.
Première étape de santé : loggez xcodebuild -version, sysctl hw.memsize, df -h comme preuve livrée.
Encodez timeouts et étages de parallèle : files dédiées pour installations lourdes ; timeout_in_minutes prudent et rétention raisonnable des xcresult.
steps:
- label: "Smoke compilation iOS"
agents:
queue: "ios"
arch: "m4"
command:
- xcodebuild -version
- df -h
- xcodebuild -scheme "App" -configuration Debug -destination "platform=iOS Simulator,name=iPhone 16" build
timeout_in_minutes: 45
Conseil : si vos pipelines distribuent encore match, suivez Fastlane + CI puis alignez clés Connect et rotation secrets Buildkite.
Lors d’updates agent, Canary le même avant/après comparaisons xcodebuild -version histogrammes — sans niveau équivalent caches GitHub, Buildkite repose encore plus sur caches locaux pérennisés et invalidées strictes autrement vos « succès caches » sont empoisonnés.
Fleet multi‑régions : encodez région dans noms/tag agents et vérifiez chemins artefacts pour éviter de confondre transferts interzones avec erreurs compil — voir aussi provisionnement multi-régions lorsque défense capex.
Ne confondez pas « toutes files vert Buildkite » et capacité saine réelle ; pod install, résolutions SPM, dents de compil n’emploient pas le même régime temps — utilisez plusieurs files exclusives lorsque mux requis (cf. nos consignes SwiftPM/Pods).
Pour tests UI Simulateur envisagez un modèle différent des pipelines compilés seuls (XCTest Simulateur, fragmentation + pools).
Formalisez la rétention des logs et des artéfacts : Buildkite agrège déjà les flux, mais les gros dossiers xcresult peuvent saturer la bande ascendante ; fixez quotas et pérennités au niveau politique plateforme.
Attention : ne continuez pas surcharger votre file alors que votre disque passe sous niveau prudent — suspendez scheduler nettoyage d’abord.
Stacks CI cohabitant sur un même Mac physique : segmentez utilisateurs ou racines de disques avant de compter uniquement sur un planning étalonné ; voir images dorées contre nœuds durables.
Quantifiez gains CI élastiques en minutes files économisées + incidents évité fenêtres livraisons — pas sous abonnement seul mais impact release.
Utiliser puces suivantes pour alignement équipe projet — adapter taille repos parallèle.
buildkite-agent --version, xcodebuild -version, piles Ruby/Pods et modèle de disque ; relancer pipeline canary après chaque mise à niveau.Les Mac de bureau dormant dérivent la chaîne d’outillage ; Linux n’expose pas officiellement la toolchain iOS Xcode. Coupler Buildkite à une exécution macOS reposant sur des nœuds dédiés, toujours joignables en SSH contractualise vos pipelines. Le hardware amorti improvisation cache pannes ; les stacks Xcode virtualisées restent fragiles (signature, simulateur). La location Cloud NodeMini Mac Mini offre généralement des extrémités SSH et niveaux SSD plus lisibles : comparez tarifs Mac mini Cloud puis Centre d’aide Cloud Mac.
Pour clôturer, rattachez ce runbook aux paliers toolchain internes : niveaux Xcode correctifs/minorités/majors impliquent des validations, des fenêtres canary et des politiques d’invalidation différentielles.
Buildkite dissocie orchestration files des manifests pipeline ; Actions verrouille sur flux PR tout en coexistant fingerprints Xcode DerivedData sous macOS. Comparez niveaux matériel tarifs Mac mini pour location cloud.
Une instance d’agent par machine généralement, la parallélisation passant par les limites et les tags ; plusieurs agents amplifient les conflits sur le trousseau et DerivedData. Questions d’implémentation : Centre d’aide Cloud Mac.
Pour une file unitaire avec visibilité coûts tout en gardant des Mac SSH en premier plan ; si vos validations GitLab ou Jenkins sont critiques, chiffrez le coût de migration puis prolongez vos lectures : GitLab Runner et Jenkins + Mac distant SSH.