Wie schätzen Sie die Zahl der Mac-Build-Rechner für Team-iOS-CI/CD? Kapazitätsplanung 2026

Ein gemeinsamer Mac-Runner ist regelmäßig belegt, während Pull-Requests auf ihre Prüfung warten.

Schnellste Lösung: Planen Sie Mac-Build-Rechner nicht nach der Zahl der Entwickler. Messen Sie Auftragsankünfte, Laufzeiten, parallele Builds und tolerierbare Wartezeiten; testen Sie den Bedarf mit repräsentativen CI-Jobs. Eine stabile Grundlast kann feste Kapazität rechtfertigen, kurzfristige Spitzen eher eine elastische Ergänzung.

Für Sie geeignet, wenn Sie die Kapazität für ein iOS-Team neu planen oder wiederkehrende Build-Warteschlangen untersuchen.
Besonders relevant für IT-Verantwortliche, CTOs, technische Leitungen und CI/CD-Plattformteams, die Kosten und Reaktionszeiten zusammen betrachten müssen.
Weniger relevant, wenn Sie zunächst eine vollständige CI/CD-Architektur oder eine Anleitung zur Benutzerverwaltung auf einem Mac benötigen.

Team-iOS-CI/CD beginnt mit den tatsächlichen Laufzeitdaten

Die entscheidende Frage lautet nicht, wie viele Personen im Team arbeiten, sondern wie viele Jobs zu welchen Zeiten eintreffen, wie lange sie einen Runner belegen und wie lange Ihr Team auf ein Ergebnis warten darf. Erst aus diesen Messwerten entsteht eine belastbare Kapazitätsannahme. Eine allgemeingültige Umrechnung von Entwicklerzahl in Mac-Anzahl gibt es nicht.

Auch ein Build ist nicht einfach ein Build. Eine schnelle Prüfung nach einer Pull-Request-Änderung kann einen anderen Ablauf haben als eine Testsuite oder eine archivierte Release-Version. Apple beschreibt Xcode-Workflows mit unterschiedlichen Aktionen wie Bauen, Testen und Archivieren in der Dokumentation zu den Aktionen eines Xcode-Cloud-Workflows. Für Ihre Planung bedeutet das: Erfassen Sie die Jobarten getrennt, statt alle CI-Läufe als gleichartige Last zu behandeln.

Dabei entstehen häufig Fehlentscheidungen, wenn nur die sichtbare Warteschlange zählt. Ein Runner kann zum Beispiel für einen Auftrag reserviert sein, obwohl der eigentliche Build noch nicht begonnen hat. Ein wiederholter Job kann die belegte Zeit verlängern, ohne dass die ursprüngliche Auslastung sofort erkennbar ist. Und eine durchschnittliche Wartezeit kann lange Verzögerungen zu Spitzenzeiten verdecken.

Weitere Kapazitätsgrenzen liegen außerhalb der Hardware. Dazu gehören parallele Ausführungsgrenzen der CI-Plattform, falsch zugewiesene Runner-Labels, Berechtigungen auf Repository-Ebene und Aufgaben, die nacheinander statt unabhängig voneinander laufen. Mehr Mac-Rechner lösen nicht automatisch ein Scheduling- oder Zugriffsproblem.

Vor dem Planen ein belastbares Lastbild erstellen

Beginnen Sie mit den Daten, die Ihre CI-Plattform bereits aufzeichnet. Sie brauchen zunächst keine theoretische Kapazitätsformel, sondern eine nachvollziehbare Darstellung der vorhandenen Last. Prüfen Sie, ob die Aufzeichnungen für jeden Job mindestens folgende Informationen enthalten:

• Zeitpunkt der Auslösung und Jobart
• Zeitpunkt, zu dem der Job einem Runner zugewiesen wird, und tatsächlicher Start
• Zeitpunkt des Abschlusses sowie Ergebnis
• Wiederholungen, Abbrüche und manuelle Neustarts
• Runner-Gruppe oder Runner-Label
• betroffene Branches, Workflows oder Projekte

Trennen Sie Pull-Request-Prüfungen, Builds des Hauptzweigs, Tests und Archivierungen. Wenn Sie außerdem Xcode CI für mehrere Projekte betreiben, sollte aus den Aufzeichnungen hervorgehen, welches Projekt und welcher Workflow einen Mac-Runner belegt. Apple erläutert in seiner Anleitung zum Bauen von Swift-Paketen und Apps in kontinuierlichen Integrationsabläufen, wie solche Builds in CI-Workflows eingebunden werden. Die konkrete Laufzeit Ihres Projekts müssen Sie trotzdem selbst messen.

Ordnen Sie die Daten nach wiederkehrenden Phasen: gewöhnliche Arbeitstage, Release-Vorbereitung, größere Testläufe oder andere planbare Ereignisse. Verwenden Sie nicht nur einen zusammengefassten Durchschnitt. Wenn sich eine Gruppe von Jobs regelmäßig zur selben Zeit staut, ist das eine andere Kapazitätsfrage als gelegentlich längere Builds ohne Warteschlange.

Auch fehlgeschlagene Jobs gehören in die Auswertung. Trennen Sie dabei technische Fehler, die einen Neustart erfordern, von Infrastrukturproblemen wie einem nicht erreichbaren Runner. Sonst schreiben Sie den zusätzlichen Ressourcenbedarf möglicherweise der falschen Ursache zu. Halten Sie außerdem fest, ob ein Auftrag auf einen bestimmten Runner festgelegt ist: Eine scheinbar freie Maschine kann für einen Job unbrauchbar sein, wenn Labels, Werkzeugumgebung oder Berechtigungen nicht passen.

Erste Bewertung: Bedarf aus Konkurrenz und Wartezeit ableiten

Für jeden Zeitraum benötigen Sie drei getrennte Beobachtungen: wie viele Jobs eintreffen, wie lange sie den Runner belegen und wie viele gleichzeitig bearbeitet werden sollen. Ergänzen Sie diese Sicht um ein überprüfbares Feedbackziel: Wie lange darf ein Entwickler bei einer Pull-Request-Prüfung warten, bevor der Ablauf die Zusammenarbeit spürbar behindert? Für Archivierungen oder geplante Tests können andere Erwartungen gelten.

Behandeln Sie dieses Ziel als Teamentscheidung, nicht als allgemeingültigen Grenzwert. Ein Team kann eine kurze Verzögerung bei einem nächtlichen Lauf akzeptieren, aber dieselbe Verzögerung bei einer interaktiven Pull-Request-Prüfung als problematisch bewerten. Notieren Sie für jede Jobklasse, welche Wartezeit akzeptabel ist und was passieren soll, wenn sie überschritten wird.

Leiten Sie daraus keine starre Maschinenzahl ab, bevor Sie die Zeitverteilung verstanden haben. Ein Beispiel für eine aussagekräftige Auswertung ist: In einem Release-Fenster treffen mehrere ähnliche Tests nahezu gleichzeitig ein; außerhalb dieses Fensters ist die Grundlast niedriger. Das weist auf einen zeitlich begrenzten Engpass hin, beweist aber noch nicht, dass dauerhaft mehr Rechner erforderlich sind. Prüfen Sie zuerst, ob Tests zeitlich verteilt oder voneinander entkoppelt werden können.

Umgekehrt kann eine anhaltende Warteschlange auch dann entstehen, wenn einzelne Jobs nicht besonders lang erscheinen. Wenn neue Aufträge regelmäßig schneller eintreffen, als verfügbare Runner sie abarbeiten, bleibt die Verzögerung bestehen. Vergleichen Sie deshalb für dieselben Zeitfenster Ankunftsrate, belegte Laufzeit und Wartezeit, statt nur die längsten Einzeljobs zu untersuchen.

Runner-Zuordnung und Plattformgrenzen getrennt prüfen

Übersetzen Sie die beobachtete Parallelität anschließend in verfügbare Mac-Runner. Dabei zählt nicht nur, wie viele Rechner eingeschaltet sind, sondern auch, welche Aufträge sie tatsächlich übernehmen können. Prüfen Sie Runner-Gruppen, Labels, Zuordnungen zu Projekten und die Zugriffsrechte auf Quellcode und Geheimnisse.

Für GitHub Actions beschreibt die Dokumentation zu selbst gehosteten Runnern die Verwaltung und Zuordnung solcher Runner. Die Referenz zur Workflow-Syntax erläutert außerdem plattformspezifische Einstellungen für Workflows und parallele Ausführung. Verwenden Sie diese Dokumente als konkrete Beispiele für GitHub Actions, nicht als Beleg dafür, dass andere CI-Systeme dieselben Limits oder Scheduling-Regeln verwenden.

Prüfen Sie in Ihrer Plattformkonfiguration insbesondere:

• ob parallele Jobs durch Kontingente oder Workflow-Einstellungen begrenzt sind;
• ob Jobs durch Labels oder Runner-Gruppen unnötig auf wenige Macs konzentriert werden;
• ob Berechtigungen den Runner-Zugriff auf das betreffende Repository verhindern;
• ob voneinander unabhängige Jobs versehentlich seriell laufen;
• ob die benötigte Xcode- und Werkzeugumgebung auf den verfügbaren Runnern vorhanden ist.

Ist die Warteschlange hauptsächlich durch eine Parallelitätsgrenze, eine ungünstige Runner-Gruppe oder einen fehlenden Zugriff verursacht, hilft ein zusätzlicher Rechner möglicherweise nicht. Erfassen Sie daher vor einer Kapazitätserweiterung die Plattformgrenzen und vergleichen Sie sie mit der tatsächlichen Runner-Belegung.

Häufige Fragen zur Mac-Kapazität

Wie viele Mac-Build-Rechner benötigt ein iOS-Team?

Leiten Sie die Zahl aus den zeitgleich anfallenden Jobs, ihrer Laufzeit und der akzeptierten Warteschlange ab. Die Entwicklerzahl sagt nicht zuverlässig voraus, wann Builds gestartet werden oder wie viel Runner-Zeit einzelne Workflows beanspruchen. Erfassen Sie Ihre Auftragsdaten nach Jobart und Lastphase, und überprüfen Sie die daraus abgeleitete Annahme anschließend mit repräsentativen Builds auf den vorgesehenen Mac-Runnern.

Wie viel Gewicht sollte die Entwicklerzahl bei der Planung haben?

Sie kann helfen, Veränderungen einzuordnen, ersetzt aber keine CI-Messwerte. Ein Team mit vielen Entwicklern kann wenige gleichzeitige Builds auslösen; ein kleineres Team kann bei automatischen Tests, mehreren Projekten oder Release-Arbeiten dennoch eine hohe Konkurrenz erzeugen. Vergleichen Sie Teamänderungen deshalb mit dem Verlauf der Jobankünfte und Runner-Auslastung. Verwenden Sie die Personenzahl nicht als feste Rechenregel.

Wann ist eine zusätzliche Runner-Kapazität sinnvoll?

Wenn eine wiederkehrende Warteschlange Ihr festgelegtes Feedbackziel verletzt, die Runner korrekt zugeordnet sind und ein Test mit zusätzlicher verfügbarer Kapazität die Verzögerung tatsächlich verringert, spricht das für eine Erweiterung. Bei vereinzelten Ausschlägen prüfen Sie zuerst Zeitplanung und Workflow-Abhängigkeiten. Die Entscheidung sollte auf einer wiederholbaren Beobachtung beruhen, nicht auf einem besonders ungünstigen Release-Tag.

Welche Verlaufsdaten brauchen Sie für eine belastbare Schätzung?

Mindestens Auslösezeit, Jobart, Wartedauer, Ausführungsdauer, Ergebnis und Wiederholungen. Ergänzen Sie Projekt, Workflow und Runner-Zuordnung, damit Sie erkennen, ob sich Jobs auf eine Gruppe konzentrieren oder an Berechtigungen scheitern. Vergleichen Sie normale Arbeitsphasen mit Release- und Testfenstern. Fehlen Start- oder Endzeiten, verbessern Sie zuerst die Erfassung, bevor Sie aus unvollständigen Daten eine Anschaffung ableiten.

Repräsentative Builds testen, bevor Sie Kapazität festlegen

Eine Schätzung wird erst dann zur Planungsgrundlage, wenn sie mit echten Workflows geprüft wurde. Wählen Sie dafür Jobs, die Ihre typischen Abläufe abbilden: beispielsweise eine Pull-Request-Prüfung, einen Build des Hauptzweigs, einen Testlauf und eine Archivierung, sofern diese Aufgaben in Ihrer Umgebung vorkommen. Apple beschreibt Abläufe und Konfigurationen für Xcode Cloud in seiner Referenz zu Xcode-Cloud-Workflows; diese Dokumentation erklärt den Dienst, ersetzt aber keine Messung Ihrer eigenen Runner.

Führen Sie die Prüfung mit repräsentativen Projekten, Branches und Berechtigungen durch. Erfassen Sie für jeden Lauf Wartedauer, Ausführungsdauer, Ergebnis und mögliche Ressourcen- oder Scheduling-Konflikte. Wiederholen Sie die Prüfung sowohl für die stabile Grundlast als auch für ein typisches Spitzenfenster. Ein einzelner erfolgreicher Durchlauf zeigt nur, dass der Job einmal funktioniert hat; er beweist nicht, dass der Ablauf unter gleichzeitiger Last die erwartete Reaktionszeit einhält.

Vergleichen Sie die Beobachtungen mit den Zielen, die Sie vor dem Test festgelegt haben. Wenn Jobs zwar warten, aber die vereinbarten Erwartungen einhalten, kann eine Optimierung der Workflows genügen. Wenn nur ein bestimmter Jobtyp blockiert, prüfen Sie dessen Abhängigkeiten und Runner-Zuordnung. Wenn sich die Warteschlange bei korrekter Konfiguration auch in wiederholten Tests nicht auflöst, testen Sie zusätzliche Kapazität.

Unterscheiden Sie dabei drei mögliche Maßnahmen: Aufgaben besser planen, dauerhaft verfügbare Runner ergänzen oder kurzfristig zusätzliche Kapazität bereitstellen. Diese Reihenfolge verhindert, dass ein Scheduling-Problem durch zusätzliche Hardware verdeckt wird. Für stabile Mac-Build-Umgebungen sind außerdem Verfügbarkeit und Zuständigkeiten relevant; prüfen Sie dazu die Informationen zur Zuverlässigkeit des Dienstes. Bei Zugriffen auf Quellcode, Signiermaterial und andere vertrauliche Daten sollten Sie parallel die Anforderungen an Datenschutz und Datenzugriff in Ihre Bewertung aufnehmen.

Kapazität regelmäßig anhand veränderter Workflows nachjustieren

Eine einmal passende Mac-Kapazität bleibt nicht automatisch passend. Neue Xcode-Versionen, zusätzliche Projekte, veränderte Testmatrizen oder längere Builds können die Auslastung verschieben. Legen Sie deshalb einen wiederkehrenden Prüfprozess fest, der die tatsächlichen CI-Aufzeichnungen einbezieht, statt die Zahl der Runner nur bei Beschwerden zu ändern.

Achten Sie bei der Prüfung auf folgende Veränderungen:

• neue oder häufiger ausgeführte Workflow-Arten;
• Verschiebungen bei Build- und Testlaufzeiten;
• mehr gleichzeitige Aufträge während Release-Phasen;
• wiederkehrende Wiederholungen oder Abbrüche;
• neue Runner-Labels, Gruppen und Repository-Zugriffe;
• Änderungen an Plattformregeln oder parallelen Ausführungsgrenzen.

Wenn die Laufzeit eines Jobs ansteigt, suchen Sie zunächst nach der Ursache: geänderte Testauswahl, zusätzliche Abhängigkeiten, ein anderer Workflow-Schritt oder Ressourcenstreit auf dem Runner. Behandeln Sie nicht jede Laufzeitänderung als Anlass, einen weiteren Mac hinzuzufügen. Apple führt in seiner Referenz zu Xcode-Umgebungsvariablen Variablen und Aktionskennungen für Xcode-Umgebungen auf. Solche Angaben helfen dabei, Unterschiede zwischen Umgebungen nachvollziehbar zu machen; sie geben jedoch keine Kapazitätswerte für Ihr Projekt vor.

Für Kostenvergleiche benötigen Sie keine fremden Pauschalwerte. Erfassen Sie die tatsächlichen Angebote und Nutzungsdaten Ihres Teams. Berücksichtigen Sie beim festen Betrieb Anschaffung, Bereitstellung, laufende Betreuung, Ausfallvorsorge und den Anteil ungenutzter Kapazität. Bei elastischer Ergänzung zählen Mietkosten, Nutzungsdauer, Bereitstellung, Netzwerkzugriff und der Aufwand, Runner zuverlässig in Ihre Workflows einzubinden. Prüfen Sie außerdem, ob die Umgebung zu Ihren Anforderungen an Datenschutz und Zugriffstrennung passt.

Fixe, elastische oder kombinierte Kapazität bewerten

Die folgende Gegenüberstellung ist ein qualitatives Bewertungsraster, keine universelle Rangliste. „Hoch“ beschreibt die relative Passung zur jeweiligen Lastform, nicht eine garantierte Leistung oder einen Preis. Ersetzen Sie jede Einschätzung durch Ihre eigenen Laufzeitdaten, Angebotswerte und betrieblichen Anforderungen.

Bewerten Sie jede Option zunächst qualitativ anhand derselben Kriterien: Warteschlange, Erfüllung Ihres Feedbackziels, Stabilität, Sicherheitsanforderungen und Gesamtkosten. Anschließend können Sie für die Kostenbewertung die realen Angebote und Nutzungsdaten einsetzen. Eine elastische Lösung ist nicht automatisch günstiger, wenn sie häufig oder dauerhaft gebraucht wird; feste Kapazität ist umgekehrt nicht automatisch wirtschaftlich, wenn sie einen großen Teil der Zeit ungenutzt bleibt.

Die nächste Erweiterung an Ihrem Lastprofil ausrichten

Wenn Ihr Team heute nur einen überlasteten, gemeinsam genutzten Runner einsetzt, drohen wiederkehrende Wartezeiten und eine schwer planbare Release-Phase. Wenn Sie dagegen für seltene Spitzen dauerhaft zusätzliche Hardware vorhalten, bezahlen Sie möglicherweise Kapazität, die außerhalb dieser Fenster kaum genutzt wird. Lokale Einzelumgebungen umgehen die gemeinsame Warteschlange nicht zuverlässig und erhöhen den Aufwand, Konfigurationen und Zugriffe einheitlich zu halten.

Prüfen Sie nach der Messung zunächst, ob Ihre CI-Konfiguration oder Workflow-Aufteilung den Engpass beheben kann. Bleibt ein klarer, kurzfristiger Zusatzbedarf, kann ein gemieteter Remote-Mac eine Möglichkeit sein, Spitzenkapazität zu ergänzen, ohne die gesamte Infrastruktur auf Dauer dafür auszulegen. Das passt allerdings nur, wenn Runner-Zugriff, Datenschutz, benötigte Werkzeuge und Betriebsabläufe mit Ihrer Umgebung vereinbar sind. Für dauerhaft hohe Last oder Anforderungen an physische Schnittstellen kann eine eigene, fest betriebene Maschine die passendere Wahl sein.

Vergleichen Sie dafür Ihr gemessenes Grundlast- und Spitzenprofil mit den verfügbaren Mac-Konfigurationen und Mietzeiträumen von SDKMac, bevor Sie eine zusätzliche Kapazität einplanen. Entscheiden Sie erst danach, ob eine Ergänzung tatsächlich zur Warteschlange, zum Sicherheitsmodell und zum Kostenrahmen Ihres Teams passt.

Häufig gestellte Fragen