GitHub dokumentiert für selbstverwaltete Runner die Zuordnung über Runner Group und Labels; fehlt ein passender, online verfügbarer Runner, wartet der Auftrag in der Warteschlange (Regeln für selbstverwaltete Runner). Leiten Sie daraus keine pauschale Knotenzahl ab: Für die Kapazitätsplanung für Mac-Knoten in der iOS-CI zählen Ihre tatsächlichen Warteschlangen, Laufzeiten, Toolchain-Anforderungen und Signierregeln. Erfassen Sie diese Daten zuerst, trennen Sie anschließend die Arbeitslasten und entscheiden Sie nach einem Pilot, ob zusätzliche oder gemietete Kapazität erforderlich ist.
Dieser Leitfaden ist für Sie gedacht, wenn Sie als IT-Verantwortlicher Mac-Ressourcen für iOS-CI planen und eine Beschaffungs- oder Mietentscheidung vorbereiten.
Als Plattformverantwortlicher prüfen Sie die Zuordnung und Warteschlangen von GitHub Actions selbstverwalteten Mac Runnern.
Als FinOps-Verantwortlicher benötigen Sie ein nachvollziehbares Modell für Kapazität und Budget.
Von der Teamgröße zur belegbaren Kapazitätsplanung für Mac-Knoten in der iOS-CI
Die Zahl der Entwickler sagt nicht aus, wie viele Mac-Aufträge gleichzeitig laufen müssen. Entscheidend ist, wie viele macOS-gebundene Jobs sich in einem bestimmten Zeitraum überschneiden, wie lange sie den Runner belegen und ob sie auf dieselbe Umgebung dürfen. Ein Team mit wenigen, langen Simulatorläufen kann andere Anforderungen haben als ein größeres Team mit kurzen, seltenen Release-Builds.
Beginnen Sie deshalb mit den Aufzeichnungen Ihrer CI-Pipeline, nicht mit einer Faustregel. Erfassen Sie pro Job-Typ den Auslöser, die Laufzeit, den Zeitpunkt der Einreihung, den tatsächlichen Start und den verwendeten Runner. Unterscheiden Sie außerdem zwischen Aufgaben, die auf macOS und Xcode angewiesen sind, und allgemeinen Prüfungen, die auf andere Runner umgeleitet werden können.
GitHub ordnet Jobs anhand der im Workflow gewählten Gruppe und Labels zu. Ein Runner muss zu diesen Kriterien passen und verfügbar sein, bevor er einen Job übernehmen kann (Workflow-Routing für selbstverwaltete Runner, Dokumentation zu Runner-Labels). Die Plattform beschreibt damit die Zuweisung, aber nicht, wie viele Mac-Knoten Ihr Unternehmen braucht. Diese Kapazitätsentscheidung muss aus Ihren eigenen Auftragsdaten hervorgehen.
| Arbeitslast | Eingaben aus Ihrer Pipeline | Typische Kapazitätsfrage | Mögliche Einschränkung |
|---|---|---|---|
| PR-Prüfungen und reguläre Builds | Auslöser, Laufzeit, Spitzenüberschneidung, macOS-Abhängigkeit | Welche Jobs müssen zeitgleich auf Mac laufen? | Allgemeine Prüfungen werden möglicherweise unnötig auf Mac geroutet |
| Simulator- und Regressionstests | Matrix-Aufteilung, Testdauer, verwendete Laufzeitumgebung | Welche Tests laufen parallel, welche teilen Ressourcen? | Toolchain- oder Umgebungsbindung kann die gemeinsame Nutzung verhindern |
| Archivierung, Signierung und Veröffentlichung | Startfenster, Freigaben, Berechtigungen, Runner-Gruppe | Können Release-Jobs mit normalen Builds koexistieren? | Geschützte Umgebungen und Signaturzugriffe begrenzen die Zuordnung |
| Spezielle oder ältere Workflows | benötigte macOS- und Xcode-Version, Architektur, Label | Braucht dieser Job einen eigenen Pool? | Ein passender Runner ist nicht automatisch im allgemeinen Pool verfügbar |
Wie viele Mac-Knoten benötigt eine iOS-CI typischerweise? Eine belastbare Antwort ergibt sich nicht aus einer branchenweiten Zahl, sondern aus Ihrem gemessenen Spitzenbedarf, der akzeptierten Wartezeit und den Isolationsregeln. Wenn Ihre Daten keinen gleichzeitigen Bedarf belegen, ist eine dauerhaft vorgehaltene zusätzliche Maschine zunächst eine Annahme, keine Kapazitätsanforderung.
Meilenstein: PR- und Hauptzweiglast erfassen
Für PR-Prüfungen und Builds des Hauptzweigs erfassen Sie getrennt, wie oft Jobs gestartet werden und wie lange sie bis zum Ende tatsächlich einen Mac Runner belegen. Prüfen Sie, ob jede Workflow-Stufe macOS benötigt. Linting, reine Formatprüfungen oder andere plattformunabhängige Schritte sollten nicht automatisch in die Mac-Kapazitätsrechnung eingehen, wenn Ihre Pipeline sie zuverlässig auf andere Runner verlagern kann.
Vergleichen Sie die Startzeit mit dem Einreihungszeitpunkt. Eine lange Joblaufzeit ohne Wartezeit weist auf eine andere Ursache als eine kurze Ausführung mit wiederkehrendem Warteschlangenaufbau hin. Halten Sie den Jobnamen und die Runner-Labels mit fest: Ein Job, der auf ein spezielles Label wartet, kann nicht zwingend von einem freien Knoten mit anderer Ausstattung übernommen werden.
Wie schätzen Sie die Anzahl selbstverwalteter Mac Runner anhand der Warteschlange? Ordnen Sie jeden wartenden Auftrag einem Job-Typ, seinen angeforderten Labels und der passenden Runner-Gruppe zu. Messen Sie anschließend, ob die Wartezeit mit gleichzeitig laufenden Jobs, mit einem fehlenden passenden Runner oder mit einem langsamen Build zusammenfällt. GitHub nennt die Regeln für seine eigenen parallelen Aufträge separat; diese Plattformgrenzen sind nicht mit der physischen Kapazität Ihrer selbstverwalteten Mac-Knoten gleichzusetzen (GitHub-Angaben zu Actions-Limits).
Simulatoren und Regressionstests getrennt gegen die Build-Last prüfen
Simulator- und Regressionstests können die Auslastung anders prägen als reguläre Builds: Sie können aus einer Testmatrix entstehen, längere Laufzeiten haben oder eine bestimmte Umgebung voraussetzen. Zählen Sie daher nicht nur die Gesamtzahl der Jobs. Erfassen Sie, wie viele Tests tatsächlich parallel ausgeführt werden, welche Runner-Labels verlangt werden und ob der Testjob dieselbe Umgebung wie ein normaler Build nutzen darf.
Bei der Planung zählt die beobachtete Belegung, nicht die theoretische Parallelität eines Workflows. Ein Workflow kann mehrere Jobs definieren, aber daraus folgt nicht, dass alle gleichzeitig gestartet werden oder dass Ihre Runner sie gleichzeitig abarbeiten. Umgekehrt kann eine Matrix bei einem Testanstieg eine Warteschlange erzeugen, obwohl die durchschnittliche CI-Last überschaubar wirkt.
Sollten PR-Builds, Simulator-Tests und Signaturveröffentlichungen auf getrennte Macs? Trennen Sie sie, wenn Ihre Sicherheitsrichtlinien, Toolchain-Anforderungen oder Messdaten eine gemeinsame Nutzung ausschließen. Wenn sie kompatibel sind und keine unvertretbaren Wartezeiten entstehen, kann ein gemeinsamer Pool genügen. Prüfen Sie diese Entscheidung anhand von Runner-Gruppen und Labels, die Jobs gezielt zu passenden Runnern leiten (Auswahl von Runner-Gruppe und Labels).
Eine getrennte Runner-Gruppe ist eine Routing- und Zugriffsentscheidung. Sie beweist für sich genommen nicht, dass die zugrunde liegenden Hosts technisch voneinander isoliert sind. Prüfen Sie Hostzugriff, Geheimnisse und Betriebssystemkonten gesondert.
Signierung und Veröffentlichung als eigene Vertrauensgrenze behandeln
Archivierung, Signierung und Veröffentlichung sollten Sie als gesonderte Arbeitslast erfassen, selbst wenn die eigentliche Build-Dauer ähnlich aussieht. Prüfen Sie, welche Zugangsdaten der Workflow benötigt, welche Personen oder Umgebungen eine Freigabe erfordern und zu welchen Zeiten Releases typischerweise starten. Ein freier Knoten ist nicht automatisch für eine Veröffentlichung geeignet, wenn ihm die erforderliche Berechtigung fehlt oder Ihre Richtlinie die gemeinsame Nutzung untersagt.
Machen Sie in der Kapazitätsrechnung sichtbar, welche Jobs aus Sicherheitsgründen exklusiv bleiben müssen. Wenn ein Release-Job nur in einem kontrollierten Pool laufen darf, kann zusätzliche allgemeine Build-Kapazität die Release-Warteschlange nicht beheben. Auch die umgekehrte Annahme ist riskant: Ein speziell für Veröffentlichung freigehaltener Runner erhöht möglicherweise den Bestand, ohne dass seine Reservierung durch Messdaten gerechtfertigt ist.
Beziehen Sie DSGVO-Anforderungen in die Gestaltung der Umgebung ein. Klären Sie, welche Projektdaten, Zugangsdaten und Protokolle auf dem Knoten verarbeitet werden, wer Zugriff erhält und wie Daten nach einem Build entfernt oder aufbewahrt werden. Bewerten Sie außerdem den Betriebszustand: Ein Knoten, der zwar existiert, aber offline ist oder nicht die geforderten Labels trägt, bietet dem wartenden Job keine nutzbare Kapazität. GitHub beschreibt die Runner-Zuordnung nach Gruppe und Labels; die organisatorischen Freigaben und Hostkontrollen legen Sie selbst fest (Informationen zu Runner Groups).
Spitzenlasten und besondere Toolchains als eigene Szenarien modellieren
Eine kurze Warteschlange während eines konzentrierten Merge-Fensters ist nicht automatisch ein Beleg für dauerhaften Kapazitätsmangel. Zeichnen Sie für Veröffentlichungen, größere Zusammenführungen und gebündelte Regressionstests auf, wie sich Warteschlange und Laufzeiten im Verhältnis zum üblichen Betrieb verändern. Legen Sie dazu ein internes Warteziel und eine Prioritätsregel fest. Diese Werte müssen zu Ihrem Release-Prozess passen; GitHub gibt damit keine allgemeingültige Unternehmensvorgabe für Ihre Mac-Knotenzahl vor.
Planen Sie außerdem für Workflows, die eine bestimmte macOS- oder Xcode-Version, eine Architektur oder eine andere festgelegte Umgebung verlangen. Fassen Sie sie nicht nur deshalb mit anderen Jobs zusammen, weil sie denselben Runner-Typ verwenden. Entscheidend ist, ob der jeweilige Runner die Anforderungen tatsächlich erfüllt und die Workflows dieselbe Vertrauensgrenze teilen. Nutzen Sie Labels und Gruppen, um die Zuordnung nachvollziehbar zu machen, und vergleichen Sie diese Zuordnung mit den realen Workflow-Ausführungen.
| Beobachtung im Betrieb | Wahrscheinliche Ursache | Nächste Prüfung | Kapazitätsreaktion |
|---|---|---|---|
| Jobs warten, obwohl andere Runner frei wirken | Die freien Runner erfüllen Gruppe oder Labels nicht | Angeforderte Labels und Gruppen mit den verfügbaren Runnern abgleichen | Fehlrouting korrigieren, bevor Sie Kapazität hinzufügen |
| Warteschlange steigt nur bei bestimmten Testläufen | Matrix- oder Regressionstests erzeugen konzentrierte Last | Testparallelität und Runner-Belegung im selben Zeitraum prüfen | Testpool oder zeitliche Steuerung im Pilot prüfen |
| Release-Jobs warten, reguläre Builds nicht | Signatur- oder Freigaberegeln begrenzen den passenden Pool | Berechtigungen und erlaubte Runner-Gruppe kontrollieren | Release-Kapazität getrennt bewerten |
| Warteschlange bleibt über verschiedene Arbeitsphasen bestehen | Basiskapazität oder Verfügbarkeit passt möglicherweise nicht zum Bedarf | Laufzeit, Ausfallzeiten und wiederkehrende Spitzen vergleichen | Zusätzliche Grundkapazität testen |
Wie reagieren Sie auf schwankende iOS-CI-Last? Trennen Sie zunächst einen kurzzeitigen Ausschlag von einer wiederkehrenden Warteschlange. Bei seltenen Spitzen kann eine befristete zusätzliche Kapazität sinnvoller sein als ein dauerhaft größerer Bestand; bei kontinuierlicher Überlastung müssen Sie zuerst Laufzeiten, Routing und Basiskapazität untersuchen. Prüfen Sie beide Varianten mit Ihren Aufzeichnungen und einem begrenzten Pilot, statt eine pauschale Reservequote anzunehmen.
Aus den Aufzeichnungen ein reproduzierbares Kapazitätsmodell ableiten
Verwenden Sie ein Modell, das ein anderer Verantwortlicher mit denselben Pipeline-Daten nachrechnen kann. Für jede Arbeitslast erfassen Sie die Zahl der Jobs im betrachteten Zeitfenster, den Anteil, der tatsächlich auf Mac laufen muss, die belegte Laufzeit und den gleichzeitig auftretenden Bedarf. Ergänzen Sie anschließend die Verfügbarkeit der passenden Runner, die Anforderungen an Isolation sowie eine ausdrücklich als Annahme markierte Spitzenreserve.
Eine einfache Form des Modells lautet:
Kapazitätsbedarf je Pool = gleichzeitige, Mac-gebundene Jobs × belegte Laufzeit × Verfügbarkeitskorrektur + separat begründete Spitzenreserve
Diese Schreibweise ist ein unternehmensinternes Rechenmodell und kein GitHub-Kennwert. „Gleichzeitige Jobs“ müssen Sie aus Ihren Workflow-Aufzeichnungen herleiten. Die Laufzeit sollte die tatsächliche Runner-Belegung abbilden, nicht nur den Abschnitt, den ein Entwickler als Build bezeichnet. Die Verfügbarkeitskorrektur muss Ihrer beobachteten Betriebsverfügbarkeit entsprechen. Die Spitzenreserve wiederum braucht eine dokumentierte Begründung aus historischen Lasten oder einem festgelegten Warteziel.
| Modellgröße | Erhebung aus Ihrer Umgebung | Prüffrage vor der Kapazitätsentscheidung |
|---|---|---|
| Auftragsvolumen und Überschneidung | Workflow- und Warteschlangenaufzeichnungen | Welche Jobs treffen zeitgleich ein, und welche benötigen zwingend macOS? |
| Belegte Laufzeit | Start- und Abschlussdaten je Job-Typ | Ist die Laufzeit stabil oder steigt sie bei bestimmten Tests? |
| Runner-Kompatibilität | Gruppen, Labels und Toolchain-Anforderungen | Welche freien Runner können diesen Job tatsächlich annehmen? |
| Verfügbarkeit und Isolation | Betriebsaufzeichnungen, Zugriffs- und Freigaberegeln | Welche Knoten sind für diesen Pool nutzbar und welche müssen getrennt bleiben? |
| Spitzenannahme | Release- und Regressionserfahrung | Ist die Reserve aus echten Lasten abgeleitet oder lediglich vorsorglich angenommen? |
Für GitHub Actions können Sie workflow_job-Ereignisse nutzen, um Änderungen am Status von Workflow-Jobs in Ihre Auswertung einzubeziehen; die dokumentierte Ereignisbeschreibung liefert die Grundlage, um Einreihung und Ausführung nach Ihrer eigenen Pipeline zuzuordnen (Dokumentation zum workflow_job-Webhook). Ergänzen Sie die Ereignisse um Runner- und Jobdaten, damit Sie erkennen, ob ein Auftrag auf einen kompatiblen Runner wartete oder ob seine Ausführung selbst länger dauerte.
Pilotphase mit klaren Entscheidungspunkten
Führen Sie die Planung als Folge von überprüfbaren Meilensteinen durch:
- Arbeitslast erfassen: Exportieren Sie Workflow-, Warteschlangen- und Laufzeitdaten für PR-Prüfungen, Tests, Signierung und Sonderfälle. Dokumentieren Sie, welche Jobs nicht auf Mac laufen müssen.
- Routing prüfen: Vergleichen Sie die in den Workflows angeforderten Labels und Runner-Gruppen mit der tatsächlichen Runner-Konfiguration. Beheben Sie Fehlzuordnungen, bevor Sie den Bedarf erhöhen.
- Pools festlegen: Gruppieren Sie kompatible Jobs. Halten Sie Signier- und Sonderumgebungen getrennt, wenn Zugriffsrichtlinien oder Toolchain-Anforderungen dies verlangen.
- Pilotkapazität testen: Ergänzen Sie nur die Kapazität, die Sie zur Prüfung Ihrer Hypothese benötigen. Messen Sie erneut Warteschlangen, Laufzeit und tatsächliche Runner-Belegung.
- Entscheidung dokumentieren: Vergleichen Sie Pilotdaten mit Ihrem Warteziel und dem Kostenrahmen. Halten Sie fest, ob die Ursache bei Routing, Laufzeit, Verfügbarkeit oder fehlender Kapazität lag.
- Ausbauen oder zurücknehmen: Erweitern Sie einen Pool nur dann, wenn der Pilot einen wiederkehrenden Engpass bestätigt. Entfernen Sie ungenutzte Zusatzkapazität oder korrigieren Sie die Annahmen, wenn die Wartezeit nicht auf einen Kapazitätsmangel zurückzuführen ist.
GitHub beschreibt für Runner Scale Sets eine Möglichkeit, Runner bedarfsgerecht zu verwalten; die Konfiguration und der Betrieb bleiben dabei Teil Ihrer Infrastrukturentscheidung (Konzept der Runner Scale Sets, Bereitstellung und Skalierung von Runner Scale Sets). Übertragen Sie eine solche Skalierungslogik nicht ungeprüft auf Ihre Mac-Umgebung: Ermitteln Sie zuerst, welche Workflows kompatibel sind und welche Lebenszyklus- und Sicherheitsanforderungen für Ihre Runner gelten.
Nutzen Sie die folgende Prüfliste unmittelbar vor einer Beschaffungs- oder Mietentscheidung:
- [ ] Sie haben allgemeine Prüfungen von macOS-gebundenen Jobs getrennt.
- [ ] Sie kennen die Warte- und Laufzeit je relevantem Job-Typ.
- [ ] Sie können für jede Warteschlange die angeforderten Labels und Runner-Gruppe nachvollziehen.
- [ ] Sie haben Simulator-, Regression- und Release-Last separat bewertet.
- [ ] Sie haben Signaturzugriffe, Freigaben und DSGVO-Anforderungen geprüft.
- [ ] Ihre Spitzenreserve ist durch gemessene Last oder ein dokumentiertes Warteziel begründet.
- [ ] Ein Pilot zeigt, ob zusätzliche Kapazität die tatsächliche Ursache behebt.
- [ ] Ihre Budgetentscheidung lässt sich mit denselben Eingabedaten erneut berechnen.
Kauf, Miete und Mischbetrieb anhand des gemessenen Bedarfs vergleichen
Eine Kaufentscheidung bindet Kapital und setzt voraus, dass Ihre Organisation Beschaffung, Wartung, Ersatz und spätere Weiternutzung selbst plant. Eine Mietlösung kann für zeitlich begrenzte Spitzen, neue Projekte oder einen Kapazitätspilot interessant sein, wenn Sie zusätzliche Mac-Ressourcen benötigen, ohne vorab dauerhaft Hardware zu beschaffen. Ein Mischbetrieb kann passen, wenn eine stabile Grundlast und variable Zusatzlast klar voneinander abgrenzbar sind.
| Entscheidungskriterium | Eigene Mac-Knoten | Gemietete Remote Macs | Mischbetrieb |
|---|---|---|---|
| Grundlast | Geeignet, wenn Bedarf dauerhaft und planbar ist | Möglich, sofern Mietzeitraum und Bedarf zusammenpassen | Grundkapazität bleibt intern, Zusatzbedarf wird ergänzt |
| Spitzen und Pilot | Zusätzliche Geräte müssen beschafft und bereitgestellt werden | Kann für begrenzte Tests oder Spitzen geprüft werden | Erlaubt eine getrennte Bewertung von Basis- und Zusatzlast |
| Betrieb und Kontrolle | Beschaffung, Wartung und lokale Kontrollen liegen bei Ihnen | Prüfen Sie Zugriff, Übergabe, Standortangaben und Vertragsbedingungen | Verantwortlichkeiten müssen für beide Betriebsmodelle feststehen |
| Eignung | Stark bei dauerhaftem Bedarf oder nötigen physischen Schnittstellen | Interessant bei variabler Last und passender Remote-Arbeitsweise | Sinnvoll, wenn Ihre CI sowohl stabile als auch schwankende Last hat |
Vergleichen Sie die Gesamtkosten mit Ihren eigenen Zahlen: Beschaffung und Abschreibung, Strom und Standortbetrieb, Wartungszeit, Ersatzplanung, administrativer Aufwand sowie die Kosten ungenutzter Kapazität. Für eine Mietoption berücksichtigen Sie dagegen Mietdauer, gewählte Konfiguration, Bereitstellung, Remote-Zugriff und die Frage, ob die Umgebung Ihre Anforderungen an Signierung und Datenkontrolle erfüllt. Ohne überprüfbare Angebote und reale Betriebsdaten wäre ein konkreter Preis- oder Einsparungswert nicht belastbar.
Wenn Ihr Pilot zeigt, dass eine temporäre Mac-Kapazität für Ihre Workflows passt, prüfen Sie die verfügbaren Angaben zu Preisen und Mietzeiträumen. Stimmen Sie die ausgewählte Umgebung anschließend mit Ihren Anforderungen an Runner-Zuordnung, Datenschutz und Release-Zugriff ab. Für Teams mit dauerhaft hoher Last, strengen Offline-Vorgaben oder benötigten physischen Schnittstellen kann der Kauf eigener Hardware geeigneter sein; eine Remote-Miete ersetzt diese Anforderungen nicht.
Feste Mac-Knoten können bei schwankender Auslastung ungenutzt bleiben und erfordern eigene Beschaffungs-, Wartungs- und Ersatzplanung. Eine gemietete Remote-Mac-Umgebung ist dagegen nicht automatisch die bessere Wahl: Sie müssen Konfiguration, Verfügbarkeit, Zugriff und Übergabe für Ihren konkreten CI-Pool verifizieren. Wenn Ihre Daten eine zeitlich begrenzte Zusatzkapazität oder einen kontrollierten Pilot nahelegen, prüfen Sie bei VMSPIN die verfügbaren Remote-Mac-Optionen und gleichen Sie die dort nachvollziehbaren Angaben mit Ihren Workflows ab, bevor Sie einen Testbetrieb ansetzen.