Eine Mac-CI-Farm auf dedizierten Mac minis betreiben

Die einzige Zahl, die zählt: wie viele Builds in Ihrer stärksten Stunde gleichzeitig laufen müssen. Nicht Entwickler, nicht Repositories, sondern parallele Builds.

Eine grobe Einteilung, die für die meisten iOS-Teams passt:

Die Wartezeit in der Queue ist das Signal. Warten Builds zu Spitzenzeiten länger als ein paar Minuten, nehmen Sie eine Maschine dazu. Das ist billiger als die Stunde, die jeder Entwickler mit Warten verbringt.

Jeder Mac mini gehört komplett Ihnen: kein Hypervisor, keine lauten Nachbarn. Damit gibt es zwei sinnvolle Muster.

Am saubersten. Ein Build bekommt die gesamte CPU, GPU und den ganzen Speicher. Nehmen Sie das für Xcode-Builds und UI-Tests, bei denen ein Build jeden Kern belegt, den Sie ihm geben.

Funktioniert, wenn Ihre Jobs klein und I/O-lastig sind: Unit-Tests, Linting, Packaging. Auf einem M4 oder M6 mit 32 GB laufen zwei leichte Jobs parallel problemlos.

Beides zu mischen ist normal: starke Maschinen nur für Release-Builds, leichtere Maschinen voll mit schnellen Jobs.

Versehen Sie Ihre Maschinen mit Labels und lassen Sie die Pipeline die Jobs dorthin leiten. Sinnvolle Aufteilungen:

ios-app, sdk, internal-tools. Jedes Repository zielt auf sein eigenes Label, damit ein kaputter Build bei einem Produkt nie ein anderes blockiert.

pr-Maschinen, die schnell und immer warm sind, release-Maschinen, die vor jedem signierten Build gelöscht werden.

Agenturen geben jedem Kunden eigene Maschinen mit eigenen Zugangsdaten und Zertifikaten. Nichts wird geteilt, nichts kann zwischen Konten durchsickern.

Alles in einem MacDuty-Konto, mit einer Rechnung am Monatsende.

Ein Mac, der ein Jahr lang baut, sammelt Xcode-Versionen, Simulatoren und Caches an. Wenn Sie eine Maschine einem neuen Projekt zuteilen, bitten Sie den Support um eine saubere Neuinstallation. Wir machen das nur mit Ihrer Freigabe, da dabei der Mac gelöscht wird.

Dieselbe Xcode-Version auf jeder Maschine eines Pools, bewusst aktualisiert. Eine Farm, in der Maschinen auseinanderdriften, liefert Builds, die auf einem Runner durchlaufen und auf einem anderen scheitern.

CPU-Graphen von Build-Maschinen sehen immer alarmierend aus und helfen selten weiter. Die Wartezeit in der Queue zeigt Ihnen, wann Sie Hardware dazunehmen sollten.

Bei zehn Maschinen sollte ein Ausfall lästig sein, kein Störfall.

Orchestrierungsplattformen legen ein Scheduling im Stil von Kubernetes über virtualisiertes macOS, und Sie bezahlen für diese Schicht. Das ist wirklich nützlich, wenn Sie in großem Maßstab kurzlebige VMs pro Job brauchen.

Die meisten Teams unter zwanzig Maschinen brauchen das nicht. Diese Teams brauchen eine Handvoll schneller, dedizierter Macs, die laufen, ihre Caches warm halten und jeden Monat gleich viel kosten. Genau das ist eine dedizierte Farm: ganze physische Maschinen zum Pauschalpreis, bei denen der Build-Cache für den nächsten Job noch da ist, statt mit der VM weggeworfen zu werden.

Dazu kommt der Unterschied, der sich um 2 Uhr nachts vor einem Release zeigt: Die Leute, die die Racks betreiben, beantworten die E-Mail.

Sagen Sie uns, wie die Farm aussehen soll: wie viele Maschinen, welche Modelle, was darauf installiert sein muss. Auf Wunsch konfigurieren wir sie mit Ihrer Xcode-Version, Ihrem Runner-Agent, Ihren Schlüsseln und Zertifikaten, und wir übernehmen Neuinstallationen und Änderungen an der Flotte im laufenden Betrieb, jeweils mit Ihrer Freigabe.