Les équipes mobile hésitent entre Bitrise cloud macOS et agents auto-hébergés sur Mac distant dédié : le premier clarifie la facturation mais fige files et images ; le second ressemble à un contrat type VPS mais exige secrets matures et hygiène disque. Public : ingénieurs plateforme et responsables iOS. Douleur : minutes, cycles de stack, pools d’agents et sessions Trousseau s’entremêlent. Livré : sept hypothèses implicites, matrice à quatre plans (liens runner GitHub Actions et GitLab Runner), runbook d’onboarding en six étapes, FAQ vers tarifs de location et centre d’aide.
Bitrise emballe YAML, marketplace de steps et tableaux de minutes ; les incidents iOS se concentrent encore là où se croisent empreintes Xcode, périmètres de signature et amplification disque. Sans ces sujets en revue, on ne discute que de logos.
Auto-hébergé ≠ zéro ops : l’agent n’est que l’exécuteur—Ruby/Bundler, caches CocoaPods/SwiftPM et DERIVED_DATA restent vos contrats, voir gouvernance dépendances & disque.
Minutes cloud + CapEx locatif ne s’additionnent pas linéairement : la finance doit modéliser les pics de semaine de release et les cœurs idle nocturnes ; les nœuds dédiés toujours allumés amortissent l’idle dans chaque build.
Ignorer les montées Xcode/stack : les jobs cloud migrent souvent seuls ; les voies self-hosted exigent workflow canari et fenêtre de rollback.
Signature sur le laptop de quelqu’un : certificats entreprise et match vont sur utilisateurs CI dédiés avec runbooks de rotation—Fastlane CI sans tête.
Mélanger Bitrise sans isolation de chemins : comme les pools de build entreprise ; les workspaces anonymes se cognent sur les trains de release.
Sous-estimer le premier passage GUI : session interactive ponctuelle via la checklist SSH vs VNC, puis retour headless.
Les tests réseau s’arrêtent au navigateur : il faut egress stable et callbacks console ; les proxies TLS laissent des workers zombies sans logs parlants.
Cause commune : traiter les Mac distants comme des locations CPU plutôt que des nœuds prod avec empreinte toolchain et arêtes conformité. Si CircleCI/Buildkite sont en jeu, lire orchestration hybride CircleCI et agent Buildkite.
Avant un second agent, publier trois métriques : profondeur de file P95, distribution durée Archive de bout en bout, delta disque hebdo. Sinon on duplique le chaos. Le matériel dédié loué améliore la prévisibilité vs laptops de bureau ; Apple Silicon réduit risques signature/review vs virtualisation douteuse—à figer dans le RFC, pas dans le chat.
Pas de solution universelle : clarifiez la proximité des workflows avec les dépôts, qui porte la facturation minute, et si la capacité macOS est physiquement dédiée.
| Axe | Bitrise cloud macOS | Bitrise self-hosted (Mac distant dédié) | GitHub Actions self-hosted | GitLab Runner (shell) |
|---|---|---|---|---|
| Plan de contrôle | Bitrise UI/API + YAML dépôt | Pareil + chemins agent et pools explicites | Labels runs-on + groupes runner | tags + périmètre d’enregistrement |
| Logique de facturation | Minutes workflow + paliers stack | Souvent double voie minutes cloud + bail fixe | Minutes Actions + amortissement matériel | Licences concurrence runner + hardware |
| Elasticité | Étapes parallèles matures | Plafonds CPU/IO honnêtes par machine | Matrices + partitions de labels | Style mutex resource_group |
| Cas typiques | Tests unitaires rapides, prototypes IPA | Archive, signing entreprise, longues intégrations et disques chauds | Équipes déjà événementielles sur GitHub | Couplage fort aux droits GitLab |
« Louer un Mac comme un VPS » dans Bitrise : garder l’ergonomie des workflows tout en verrouillant Xcode + secrets + NVMe derrière un hôte dédié contractuel.
Si les Steps collent déjà mais quelques jobs lourds exigent disque et domaines de signature prévisibles : validations légères sur stacks cloud, builds lourds vers pools self-hosted, via conditions explicites. La pression de pic passe de « crédits » à « votre file », les échecs se rapprochent des hôtes SSH.
Documentez RACI pour « qui mute la signature » et « qui purge les caches » sur Bitrise/GitHub/GitLab—sinon trois pipelines paginent le jour d’expiration des certificats. Réutilisez la grille achat vs location TCO avant de basculer les stacks.
Ordre : identités et répertoires, puis enregistrement d’agent, enfin parallélisme. Les libellés suivent la doc Bitrise actuelle—ici le squelette d’ingénierie.
Utilisateur CI macOS dédié : ne jamais mélanger avec des sessions Apple ID perso ; préfixe type ~/bitrise-ci.
Geler les empreintes toolchain : xcodebuild -version, Ruby, Bundler dans la doc du dépôt.
Installer/enregistrer l’agent self-hosted selon le guide : tokens d’inscription = secrets rotatifs avec fenêtre d’expiration dans le runbook.
Lier les workflows au bon stack/pool : les défauts pointent encore souvent vers des workers cloud.
Workflow hello : checkout + xcodebuild -list pour fermer la boucle file→hôte.
Canari sur le même SHA Git cloud vs self-hosted avant de monter la parallélisation.
xcodebuild -version sysctl hw.memsize hw.ncpu df -h / /usr/bin/security find-identity -v -p codesigning
Remarque : désactiver la veille système et vérifier LaunchDaemon/LaunchAgent après reboot—sinon « vert le jour, rouge la nuit » feint une panne Bitrise.
Après fermeture de boucle, brancher la surveillance sur temps d’attente file et seuil disque hôte : le premier révèle les pools mal liés, le second les politiques de cache folles. Croiser avec parallélisme XCTest—tests UI vs jobs compilation ont des profils IO différents.
Tableaux verts ≠ CPU idle : résolution des deps, compilation et pics de signature se décalent—poser des plafonds honnêtes via mutex ou files dédiées. Les Mac distants dédiés battent laptops partagés ou VMs fragiles sur latence NVMe et continuité Trousseau ; sans garde-fous disque, artefacts git/Xcode à moitié écrits le vendredi soir.
Attention : suspendre le scheduling sous le seuil disque d’équipe ; nettoyer volontairement et journaliser les chemins supprimés pour audit.
La finance doit suivre « heures d’urgence évitées en semaine de release » et « achats minutes cloud d’urgence évités », pas seulement le prix unitaire. Les voies self-hosted échangent factures Bitrise visibles contre patches, montées Xcode et agents ; le datacenter pur rapatrie la maintenance, l’hébergement loué regroupe souvent la logistique multi-régions — tout noter trimestriellement.
RGPD : ne conservez logs et artefacts que le temps nécessaire aux preuves ; fixez la rétention dans le runbook et tracez les accès.
Sécurité : self-hosted exécute des scripts dépôt arbitraires—traiter les hôtes comme prod : rotation clés SSH, auth par clé uniquement, sudo minimal, comptes build isolés. Croiser empreintes de build reproductibles pour chaque bump toolchain avec workflows canari et tags de rollback.
Ajuster les seuils à la masse du dépôt et à la politique de parallélisme.
Les laptops empruntés perdent contre veille et mises à jour surprises ; la virtualisation macOS grise échoue aux audits. Garder Bitrise comme orchestrateur familier et poser l’exécution macOS sur des nœuds dédiés, toujours allumés, adaptés SSH fait passer les pipelines en niveau « contrat ». Face au matériel perso jetable ou aux hôtes partagés opaques, NodeMini location cloud Mac Mini clarifie contrats SSH, paliers disque et profils reproductibles pour iOS CI/CD et automatisation. Comparez les SKU via les tarifs et l’onboarding via le centre d’aide.
Lier ce runbook aux niveaux de changement toolchain internes : bumps Xcode mineurs/majeurs avec approbations et invalidations cache distinctes—éviter « tout rouge après upgrade » sans frontière signature/disque attribuable.
Le cloud excelle sur stacks curatés et minutes élastiques ; le dédié sur secrets et caches chauds. Jobs légers cloud, signing lourd self-hosted. Comparez d’abord les paliers sur les tarifs.
Isoler DerivedData et caches par utilisateur Unix ou racine de montage ; séparer les trousseaux de signature. Onboarding centre d’aide + articles runner détaillés.
Vérifier process agent et politiques de veille, puis liaison pool/stack ; si les proxies interceptent HTTPS, la console peut n’afficher que des symptômes indirects—capturer des preuves paquets côté hôte.