Ein belastbarer Kapazitätsplan beginnt mit dem Build Timing Summary von Xcode: Dort lassen sich die Zeiten einzelner Build-Schritte auswerten, statt nur eine gefühlte Gesamtdauer zu verwenden. Apple beschreibt diese Messmethode in der Xcode-Dokumentation. Für die Mac mini M4 Kapazitätsplanung bedeutet das: Die Anzahl der Build-Maschinen darf nicht aus der Entwicklerzahl oder aus M4-Hardwaredaten abgeleitet werden. Benötigt werden Spitzenlast, P95-Dauer je Workload, zulässige Wartezeit, effektive Auslastung und Ausfallreserve. Ein nicht kritischer Pilot startet mit einem validierten Einzelknoten. Eine produktive Pipeline benötigt eine Basiskapazität plus unabhängige Reserve oder einen elastischen Remote Mac.
[ SECTION_01 ] Kapazitätsentscheidung in vier Messwerten
Diese Analyse richtet sich an IT-Verantwortliche, die für ein neues iOS-Team ein Budget erstellen. Sie ist außerdem für Verantwortliche der Entwicklungsproduktivität gedacht, deren Build-Warteschlange bereits Merge- oder Release-Ziele gefährdet.
CTOs und technische Leiter erhalten ein Entscheidungsmodell für die Wahl zwischen fest beschafften Mac mini M4, einem festen Knotenpool und einer Kombination aus eigener Kapazität und elastischen Remote Macs.
| Eingabe | Was wird gemessen? | Quelle | Konsequenz für die Planung |
|---|---|---|---|
| Spitzenankunftsrate | Anzahl eingehender Jobs im relevanten Hochlastfenster | CI-Queue und Jobprotokolle | Bestimmt die benötigte Arbeitsmenge |
| P95-Buildzeit | Zeit, die 95 % der vergleichbaren Jobs nicht überschreiten | CI-Logs und Xcode Build Timing Summary | Verhindert eine Planung mit unrealistisch kurzen Mittelwerten |
| Zielwartezeit | Maximale Zeit bis zum Start eines Jobs | Service-Level für Merge oder Release | Setzt die Erweiterungsschwelle |
| Unterbrechungsbereich | Welche Jobs dürfen bei einem Knotenausfall warten? | Release- und Notfallprozess | Bestimmt die unabhängige Reserve |
Fehlt einer dieser Werte, ist die Frage „Wie viele Mac mini M4 braucht das Team?“ nicht zuverlässig beantwortbar. Ein Monatsmittel kann eine kurze Release-Spitze vollständig verdecken. Eine dauerhaft niedrige CPU-Auslastung beweist ebenfalls nicht, dass die Pipeline genügend Kapazität besitzt. Entscheidend ist, ob Jobs während des relevanten Zeitfensters innerhalb der vereinbarten Wartezeit starten.
Ein iOS-Entwicklungsteam braucht wie viele Mac mini M4 für CI?
Eine allgemeingültige Anzahl gibt es nicht. Ein Team mit wenigen, aber langen UI-Test- und Archive-Jobs kann mehr Kapazität benötigen als ein größeres Team mit kurzen inkrementellen Builds. Die Entscheidung muss aus Jobankunft, P95-Dauer und Zielwartezeit entstehen.
Vor der Hardwareerweiterung werden fehlerhafte Pipeline-Schritte ausgeschlossen. Dazu gehören unnötige Vollbuilds, nicht reproduzierbare Abhängigkeiten, blockierende Skripte, fehlende Caches und falsch konfigurierte Zielabhängigkeiten. Erst wenn die verbleibende Last gemessen wurde, ist zusätzliche Hardware ein begründbarer Ausgabenposten.
Hinweis: Ein kurzfristiger CPU-Peak ist kein ausreichender Erweiterungsgrund. Die Queue muss das vereinbarte Wartezeitziel wiederholt überschreiten. Einzelne Ausreißer gehören in die Ursachenanalyse, nicht automatisch in die Einkaufsplanung.
[ SECTION_02 ] Arbeitslast und Nachfrageprofil
Ein Build-Job ist nicht gleich ein Build-Job. Code-Prüfung, Unit-Tests, UI-Tests, Archive und Signierung belasten den Knoten unterschiedlich. Ein einziger Durchschnittswert verschleiert diese Unterschiede und führt häufig zu einer zu kleinen Basiskapazität.
| Workload | Typische Messgröße | Im Modell verwenden | Besondere Prüfung |
|---|---|---|---|
| Code-Prüfung | Dauer und Jobanzahl pro Zeitfenster | P95-Dauer der Prüfjobs | Werden Prüfungen bei jedem Merge ausgelöst? |
| Unit-Tests | Testdauer und Zielabhängigkeiten | P95-Dauer je Testprofil | Gibt es serielle Testabschnitte? |
| UI-Tests | Simulatorlaufzeit und Gerätezugriff | P95-Dauer je Testgruppe | Entsteht Konkurrenz um Simulator- oder Arbeitsverzeichnisse? |
| Archive | Archivdauer und Artefaktgröße | P95-Dauer der Archive | Wird ein vollständiger Build erzwungen? |
| Signierung und Veröffentlichung | Dauer der Signatur- und Uploadschritte | P95-Dauer des Releasepfads | Sind Zertifikate und Schlüssel isoliert? |
Die Rohdaten sollten aus dem Hochlastfenster stammen. Dafür werden geplante Nachtläufe, Merge-Anfragen und Release-Jobs getrennt gezählt. Wenn diese Gruppen zeitlich überlappen, wird ihre Arbeitsmenge addiert. Die Eingangsarbeit lässt sich als Summe ausdrücken:
Spitzenarbeitsmenge = Σ (Jobanzahl je Workload × P95-Dauer je Workload)
Die Zeiteinheit muss in allen Variablen gleich sein. Ein Job, der nur auf einen freien Simulator oder ein reserviertes Signierungsprofil wartet, darf nicht als reine Rechenzeit behandelt werden. Queue-Zeit und Ausführungszeit werden getrennt gespeichert.
Wie wird die Anzahl der Mac-Build-Knoten aus der Warteschlange berechnet?
Zuerst wird die Spitzenarbeitsmenge durch die nachgewiesene effektive Stundenleistung eines Knotens geteilt. Danach werden Zielwartezeit, Parallelitätsverlust und Reserve berücksichtigt. Das Ergebnis wird immer auf die nächste ganze Maschine aufgerundet:
Basisknoten = Aufrunden(Spitzenarbeitsmenge ÷ effektive Knotenleistung)
Diese Formel liefert nur eine Ausgangsgröße. Sie garantiert noch keine kurze Wartezeit. Wenn viele Jobs gleichzeitig eintreffen, kann ein rechnerisch ausreichend ausgelasteter Pool trotzdem eine lange Schlange erzeugen. Deshalb wird die Rechnung mit echten Queue-Verläufen und einem Belastungstest überprüft.
Die Dokumentation zu Xcode Build Phases hilft dabei, Skripte, Kopiervorgänge und weitere Arbeitsschritte innerhalb eines Targets sichtbar zu machen. Das ist wichtig, weil ein serieller Skriptabschnitt die theoretische Parallelität begrenzen kann.
[ SECTION_03 ] Knotenleistung statt Datenblattwert
Die offiziellen technischen Daten eines Mac mini M4 oder Mac mini M4 Pro definieren den möglichen Hardware-Rahmen. Sie liefern jedoch keine verlässliche Zahl für Xcode-Builds pro Stunde. Projektstruktur, Swift-Code, Abhängigkeiten, Simulatoren, Cache-Zustand, Xcode-Version und Signierung verändern die tatsächliche Leistung. Die offiziellen Mac-mini-Spezifikationen sind daher für die Konfigurationsprüfung relevant, nicht für die Durchsatzprognose.
Ein belastbarer Benchmark verwendet:
- denselben Commit oder eine eindeutig versionierte Codebasis,
- dieselbe Xcode-Version und dasselbe SDK,
- denselben Zustand externer Abhängigkeiten,
- getrennte Tests für kalten und inkrementellen Build,
- identische Cache- und DerivedData-Regeln,
- dieselben Signierungs- und Archivschritte,
- mehrere Wiederholungen über ein zusammenhängendes Testfenster.
Die Pipeline protokolliert für jede Wiederholung Startzeit, Ende, Cache-Zustand, Ziel, Exit-Status und Wartezeit. Ein einzelner besonders schneller Lauf wird nicht zur Norm erklärt. Für die Kapazitätsformel wird die P95-Dauer der jeweiligen Arbeitslast verwendet.
Wie viele Xcode-Builds kann ein Mac mini M4 gleichzeitig ausführen?
Das lässt sich nicht aus der Chipbezeichnung beantworten. Mehrere Jobs können sich Arbeitsspeicher, SSD-I/O, Simulatoren, DerivedData, Keychain und Netzwerkzugriffe teilen. Die akzeptable Zahl paralleler Jobs muss aus einem Drucktest mit dem echten Projekt stammen. Steigt die Jobdauer oder die Fehlerquote deutlich, ist ein zusätzlicher Parallelitätsslot keine echte Kapazität.
Xcode bietet mit dem Build Timing Summary einen Ansatz, um langsame Phasen und Abhängigkeiten zu untersuchen. Die Hinweise zur Beschleunigung inkrementeller Builds sollten vor einer Hardwareentscheidung ausgewertet werden. Ein unnötig serialisierter Build kann sonst als „zu langsamer Mac“ erscheinen.
Ein weiterer Prüfpunkt sind Zielabhängigkeiten. Xcode beschreibt die Konfiguration von Build-Schemata und parallelen Builds. Wenn ein Projekt wegen seiner Abhängigkeiten kaum parallel arbeiten kann, bringt ein stärkerer Rechner möglicherweise mehr als ein weiterer Knoten. Sind dagegen viele unabhängige Jobs vorhanden, verbessert ein zusätzlicher Knoten oft die Queue-Situation stärker als ein Upgrade einzelner Hardware.
[ SECTION_04 ] Parallelität und Isolation
Die Papierkapazität sinkt, sobald mehrere Jobs denselben Zustand verwenden. Besonders kritisch sind:
- gemeinsam genutzte DerivedData-Verzeichnisse,
- Simulatorzustände und simulierte Geräte,
- Arbeitsverzeichnisse mit wechselnden Artefakten,
- Keychain-Einträge und Signierungsprofile,
- temporäre Dateien mit vertraulichen Quelldaten,
- konkurrierende Uploads und Artefaktablagen.
Ein einzelner Mac mit mehreren parallelen Jobs kann auf dem Papier günstiger sein. Er besitzt aber einen gemeinsamen Fehlerbereich. Ein beschädigtes Arbeitsverzeichnis, ein hängender Simulator oder ein fehlerhafter Signierungszustand kann mehrere Jobs gleichzeitig blockieren. Mehrere Knoten erhöhen dagegen die Zahl der Umgebungen, die bereinigt, gepatcht und überwacht werden müssen.
| Betriebsmodell | Durchsatz | Fehlerbereich | Verwaltungsaufwand | Geeigneter Einsatz |
|---|---|---|---|---|
| Ein Job pro Knoten | Vorhersagbarer | Klein | Höher bei vielen Maschinen | Release, Signierung, sensible Projekte |
| Mehrere Jobs pro Knoten | Kann bei kurzen Jobs hoch sein | Größer | Komplexe Isolation und Bereinigung | Kontrollierte Merge-Validierung |
| Gemischte Slots | Abhängig vom Workload | Unterschiedlich | Erfordert Routingregeln | Teams mit stark wechselnden Lasten |
Die Kennzahl „Parallelität“ wird nur akzeptiert, wenn sie unter realer Last stabil bleibt. Dazu gehören erfolgreiche Builds, P95-Dauer, Queue-Zeit und Fehlerquote. Ein Slot, der regelmäßig Ressourcenprobleme auslöst, wird aus der effektiven Knotenleistung entfernt.
Soll ein iOS-CI-System einen stärkeren Mac oder mehr Knoten erhalten?
Ein stärkerer Knoten ist sinnvoll, wenn ein einzelner Job durch CPU, I/O oder Arbeitsspeicher begrenzt ist und die Pipeline überwiegend seriell arbeitet. Mehr Knoten sind sinnvoll, wenn unabhängige Jobs gleichzeitig warten und ein einzelner Fehler nicht den gesamten Releasepfad blockieren darf. Bei gemischter Last ist ein fester Basisknoten mit zusätzlichen elastischen Knoten häufig besser prüfbar als eine pauschale Aufrüstung.
Für die Zugriffssteuerung sollten Runner nach Workload, Repository und Schutzbedarf gruppiert werden. Die Anleitung zu Labels und Gruppen für selbst verwaltete Runner zeigt das zugrunde liegende Prinzip: Routing muss explizit sein. Für ein Unternehmen bedeutet das, dass Signierungsjobs nicht zufällig auf einem gemeinsam genutzten Knoten landen dürfen.
[ SECTION_05 ] Warteschlange und Erweiterungsschwelle
Die Basisgröße wird aus der Arbeitsmenge berechnet. Die operative Größe entsteht erst durch das gewünschte Service-Level. Drei Lastprofile sollten getrennt bewertet werden:
| Serviceziel | Vorrangige Kennzahl | Kapazitätsentscheidung | Reservebedarf |
|---|---|---|---|
| Nacht- und Planläufe | Abschluss bis zum nächsten Arbeitsfenster | Geringere Basis möglich, wenn Wartezeit akzeptiert wird | Wartungsfenster muss eingeplant werden |
| Merge-Validierung | Start innerhalb des definierten Queue-Ziels | Zusätzliche Knoten bei wiederholter Zielüberschreitung | Mindestens ein unabhängiger Ausweichpfad wird geprüft |
| Release-Fenster | Verfügbarkeit und Startbereitschaft | Basiskapazität für Spitzenlast plus Reserve | Ausfall eines Knotens darf den Release nicht vollständig stoppen |
Bei welcher Auslastung muss ein Mac-Build-Pool erweitert werden?
Es gibt keinen universellen Prozentwert, der für alle Projekte gilt. Die Erweiterung beginnt, wenn die gemessene Warteschlange das vereinbarte Ziel wiederholt überschreitet oder die Reserve im Hochlastfenster nicht mehr verfügbar ist. Die Auslastung dient als Warnsignal. Sie ersetzt nicht die Beobachtung von P95-Wartezeit und Jobankunftsrate.
Die effektive Leistung eines Knotens lautet:
effektive Knotenleistung = erfolgreiche Arbeitsmenge ÷ gemessene Betriebszeit
Abgezogen werden Wartung, Bereinigung, wiederholte Jobs wegen Infrastrukturfehlern und Kapazitätsverluste durch Isolation. Für die Endplanung gilt:
Gesamtknoten = Aufrunden(Basisknoten × Auslastungspuffer) + unabhängige Reserve
Der Auslastungspuffer bleibt eine organisationsspezifische Variable. Er wird aus den eigenen Queue-Verläufen abgeleitet. Ein Unternehmen mit tolerierter Nachtwartezeit plant anders als ein Unternehmen, dessen Release-Fenster an ein externes Abgabedatum gebunden ist.
Erfahrungshinweis: Eine Maschine, die im Mittel ausreichend ausgelastet ist, kann im entscheidenden Release-Fenster dennoch unbrauchbar sein. Die Kapazitätsprüfung muss deshalb nach Zeitfenstern und Workload-Klassen erfolgen, nicht nach einem monatlichen Gesamtmittel.
[ SECTION_06 ] Kostenmodell und Auswahl
Die Budgetentscheidung besteht nicht nur aus dem Kaufpreis eines Mac mini. Relevant sind auch Ersatzhardware, Wartung, Strom, Standort, Monitoring, Bereinigung, Administrationszeit und die Kosten blockierter Entwickler. Bei einer gemieteten Remote-Mac-Kapazität kommen Mietperiode, Zugriffsverwaltung, Netzwerkpfad und gegebenenfalls Datenübertragung hinzu.
Konkrete Preise werden nur eingesetzt, wenn sie aus einem verbindlichen Angebot oder einer geprüften Tarifseite stammen. Ohne diese Daten wäre eine scheinpräzise Jahresrechnung nicht belastbar.
| Kostenblock | Fester Mac-mini-Pool | Elastischer Remote Mac | Gemischtes Modell |
|---|---|---|---|
| Investition | Hardwarekauf und Ersatzreserve | Keine vollständige Vorabinvestition für Zusatzkapazität | Feste Basisinvestition plus variable Kapazität |
| Laufende Kosten | Standort, Strom, Wartung, Monitoring | Mietkosten und Betriebszugang | Beide Kostenarten |
| Überkapazität | Wird auch außerhalb von Spitzen genutzt | Nur bei Bedarf aktivierbar, abhängig von Verfügbarkeit | Spitzen werden ausgelagert |
| Ausfallkosten | Eigene Ersatz- und Wiederherstellungsprozesse | Abhängig von Anbieterprozess und Zugriffsweg | Fehlerdomänen werden getrennt |
| Administration | Patchen, Bereinigen, Zertifikate, Inventar | Zugriffs- und Pipelineverwaltung | Höchste Architekturkomplexität, aber flexible Lastverteilung |
Die Mac-mini-M4-Übersicht von NOVAKVM kann als Ausgangspunkt für eine konkrete Verfügbarkeits- und Mietanfrage dienen. Sie ersetzt keinen Projektbenchmark. Vor einer Bestellung sollte dieselbe Testpipeline auf dem vorgesehenen Remote Mac ausgeführt werden.
Für die Entscheidung werden drei Szenarien unterschieden:
- Nicht kritischer Pilot: Ein Knoten genügt, wenn Buildzeiten, Signierung und Bereinigung reproduzierbar geprüft werden können. Der Pilot darf keine produktive Release-SLA versprechen.
- Stabile Alltagspipeline: Eine feste Basiskapazität deckt die normale Merge-Last ab. Ein unabhängiger Ersatzknoten oder eine klar getestete elastische Ergänzung schützt vor Wartung und Einzeldefekten.
- Kritischer Releasepfad: Die Basiskapazität wird auf das Release-Fenster ausgelegt. Signierung, Artefakte und Zugriff werden getrennt betrachtet. Ein einzelner gemeinsamer Knoten ist nur dann vertretbar, wenn die Unterbrechung ausdrücklich akzeptiert wird.
Die wirtschaftliche Formel lautet:
Gesamtkosten = feste Knotenkosten + elastische Kapazitätskosten + Wartekosten
Wartekosten umfassen blockierte Entwicklungszeit, verspätete Merge-Entscheidungen und verschobene Veröffentlichungen. Sie werden mit der tatsächlich gemessenen Queue-Zeit bewertet, nicht mit einer pauschalen Annahme.
[ SECTION_07 ] Prüfliste für die Kapazitätsfreigabe
- [ ] Spitzenankunftsrate für Merge-, Test- und Release-Jobs aus CI-Logs exportieren.
- [ ] P95-Buildzeit je Workload statt eines Gesamtmittelwerts berechnen.
- [ ] Kalte, inkrementelle, Test- und Archive-Läufe mit derselben Xcode-Version messen.
- [ ] Build Timing Summary und Build Phases auf serielle oder unnötige Arbeit prüfen.
- [ ] Cache-Zustand, DerivedData und Abhängigkeitsquellen dokumentieren.
- [ ] Simulator-, Keychain- und Arbeitsverzeichnis-Isolation für parallele Jobs testen.
- [ ] Effektive Knotenleistung aus erfolgreichen Läufen und realer Betriebszeit ableiten.
- [ ] Zielwartezeit für Nachtläufe, Merge-Validierung und Releases getrennt festlegen.
- [ ] Wartung, Host-Ausfall und Xcode-Upgrade als eigene Reservefälle modellieren.
- [ ] Kosten fester Kapazität, elastischer Kapazität und Wartezeit nebeneinanderstellen.
- [ ] Einen Remote Mac mit derselben Benchmark-Pipeline testen, bevor ein Mietpool freigegeben wird.
- [ ] Erweiterung erst auslösen, wenn Queue-Ziel oder Reserve wiederholt verfehlt werden.
Diese Liste verhindert, dass ein Team allein anhand der Zahl der Entwickler oder der Anzahl der CPU-Kerne einkauft. Sie schafft außerdem eine nachvollziehbare Dokumentation für Einkauf, Informationssicherheit und technische Leitung.
[ SECTION_08 ] Entscheidung für die nächste Ausbaustufe
Wenn die gemessene Last niedrig und eine längere Wartezeit zulässig ist, reicht ein validierter Einzelknoten für den Pilotbetrieb. Wenn tägliche Merge-Jobs regelmäßig warten, wird zunächst geprüft, ob Pipeline-Optimierung die Arbeitsmenge senkt. Bleibt die Nachfrage bestehen, wird die Basiskapazität erweitert.
Wenn Release-Jobs und normale Merge-Jobs konkurrieren, sollten sie nicht zwingend dieselben Ressourcen verwenden. Ein eigener Releasepfad reduziert den gemeinsamen Fehlerbereich. Bei stark schwankender Nachfrage kann ein fester Kern mit zusätzlicher Remote-Mac-Kapazität sinnvoll sein. Dabei müssen Zugriff, DSGVO-Anforderungen, Datenstandort, Signierung und Wiederherstellung vorab geprüft werden.
Ein Leitfaden zu NOVAKVM Remote-Mac-Zugängen ist in diesem Stadium nur der nächste Prüfpunkt, nicht die Kapazitätsberechnung selbst. Entscheidend bleibt, ob die gemessene Umgebung dieselbe Codebasis, Xcode-Version und Cache-Strategie abbildet. Erst dann darf die gemessene Knotenleistung in das Modell übernommen werden.
Wer die gesamte Spitzenlast dauerhaft auf eigene Mac mini M4 verteilt, bezahlt auch für Kapazität außerhalb des Spitzenfensters. Wer ausschließlich auf spontane externe Kapazität setzt, muss dagegen Verfügbarkeit, Zugriffslatenz und Compliance nachweisen. Ein hybrider Ansatz ist daher weder automatisch günstiger noch automatisch besser. Er passt, wenn die Tageslast stabil ist, die Release-Spitzen aber deutlich darüber liegen.
Ein fester Mac-Pool bietet volle Kontrolle, verursacht jedoch Vorabinvestitionen, Wartungsaufwand und einen gemeinsamen Betriebsverantwortungsbereich. Eine vollständig lokale Lösung bleibt für dauerhaft hohe, planbare Last und Anforderungen an physische Schnittstellen plausibel. Für kurzfristige Tests, schwankende Release-Spitzen und zusätzliche CI/CD-Slots kann ein Remote Mac dagegen schneller bereitgestellt werden, ohne sofort weitere Hardware zu beschaffen.
Der sinnvolle nächste Schritt ist deshalb kein pauschaler Kauf einer bestimmten Stückzahl. Das Team sollte die Lasttabelle ausfüllen, die Benchmark-Aufträge auf einem realen Mac ausführen und die Ergebnisse in die Variablen Spitzenarbeitsmenge, P95-Dauer, effektive Knotenleistung und Reserve einsetzen. Wenn die Differenz zwischen Normalbetrieb und Release-Spitze groß ist, sollte NOVAKVM als elastische Ergänzung zu einer festen Basiskapazität geprüft werden. So entsteht eine Entscheidung auf Basis nachweisbarer Builddaten statt auf Basis von Entwicklerzahl, Datenblatt oder einer einmaligen CPU-Spitze.