Faire tourner une ferme CI Mac sur des Mac mini dédiés

Le seul chiffre qui compte est le nombre de builds qui doivent tourner en même temps pendant votre heure la plus chargée. Ni les développeurs, ni les dépôts : les builds simultanés.

Un ordre de grandeur valable pour la plupart des équipes iOS :

Le temps d'attente dans la file est le signal. Si les builds attendent plus de deux ou trois minutes en pointe, ajoutez une machine. Cela coûte moins cher que l'heure que chaque développeur passe à attendre.

Chaque Mac mini vous donne la machine entière : pas d'hyperviseur, pas de voisin bruyant. Cela vous laisse deux schémas valables.

Le plus propre. Un build dispose de tout le CPU, du GPU et de la mémoire. À utiliser pour les builds Xcode et les tests UI, où un build consomme volontiers tous les cœurs que vous lui donnez.

Convient quand vos jobs sont petits et limités par les E/S : tests unitaires, lint, packaging. Sur un M4 ou un M6 de 32 GB, deux jobs légers en parallèle passent sans problème.

Mélanger les deux est normal : des machines lourdes dédiées aux builds de release, des machines plus légères remplies de jobs rapides.

Étiquetez vos machines et laissez le pipeline les cibler. Les découpages utiles :

ios-app, sdk, internal-tools. Chaque dépôt cible son propre label, si bien qu'un build cassé sur un produit n'en bloque jamais un autre.

Des machines pr rapides et toujours chaudes, des machines release effacées avant chaque build signé.

Les agences donnent à chaque client ses propres machines, avec ses propres identifiants et certificats. Rien de partagé, rien qui puisse fuiter d'un compte à l'autre.

Le tout sur un seul compte MacDuty, avec une seule facture en fin de mois.

Un Mac qui builde depuis un an accumule des versions d'Xcode, des simulateurs et des caches. Quand vous affectez une machine à un nouveau projet, demandez au support une réinstallation propre. Nous ne la faisons qu'avec votre accord, car elle efface le Mac.

La même version d'Xcode sur toutes les machines d'un pool, mise à jour de façon délibérée. Une ferme où les machines divergent produit des builds qui passent sur un runner et échouent sur un autre.

Les graphiques CPU des machines de build sont toujours alarmants et rarement exploitables. Le temps d'attente dans la file vous dit quand ajouter du matériel.

À dix machines, une machine en panne devrait être une gêne, pas un incident.

Les plateformes d'orchestration ajoutent un ordonnancement à la Kubernetes au-dessus de macOS virtualisé, et vous payez cette couche. Elle est vraiment utile si vous avez besoin de VM éphémères lancées pour chaque job à grande échelle.

La plupart des équipes de moins de vingt machines n'en ont pas besoin. Il leur faut quelques Mac dédiés et rapides qui restent allumés, gardent leurs caches chauds et coûtent le même montant chaque mois. C'est ce qu'est une ferme dédiée : des machines physiques entières à prix fixe, avec le cache de build toujours là pour le job suivant au lieu d'être jeté avec la VM.

Vous avez aussi la différence qui se voit à 2 h du matin avant une release : les personnes qui gèrent les baies répondent à l'e-mail.

Décrivez-nous la ferme voulue : combien de machines, quels modèles, ce qu'il faut installer dessus. Sur demande, nous les configurons avec votre version d'Xcode, votre agent runner, vos clés et vos certificats, et nous gérons les réinstallations et les changements de parc au fil de l'eau, chaque fois avec votre accord.