Unterbricht das Upgrade auf macOS 26.6 die Mac-CI? Unternehmenswartung 2026

Die wichtigste Grenze ist nicht der Name des Betriebssystems, sondern die Toolchain-Kopplung. Wenn ein Projekt Xcode 27 benötigt, muss der betreffende Build-Knoten die von Apple dokumentierte Systemvoraussetzung erfüllen. Ein älterer Knoten, der weiterhin mit einer freigegebenen älteren Xcode-Version baut, muss nicht automatisch am selben Tag aktualisiert werden.

Damit entstehen mindestens drei getrennte Betriebsgruppen:

Die Xcode-Systemanforderungen von Apple sind daher ein Freigabekriterium für die jeweilige Pipeline, nicht automatisch eine Anweisung zur gleichzeitigen Aktualisierung des gesamten Pools.

Automatische Updates und laufende Builds

Ein laufender Build schützt den Host nicht zuverlässig vor einem verwalteten Neustart. Apple beschreibt für verwaltete Softwareupdates Szenarien, in denen ein Update erzwungen, ein Neustart angefordert oder ein Neustart zeitlich gesteuert werden kann. Welche Option tatsächlich greift, hängt von der verwendeten Verwaltungsplattform und ihrer Konfiguration ab. Die Apple-Dokumentation zu Softwareupdates darf deshalb nicht als Beleg dafür verwendet werden, dass jeder CI-Agent jeden laufenden Job schützt.

Für die Betriebspraxis gilt:

• Ein Update darf nicht auf einem Knoten starten, der noch neue Jobs annimmt.
• Ein laufender Job muss entweder beendet oder kontrolliert abgebrochen werden.
• Ein Host mit erreichbarem Netzwerk ist noch kein einsatzbereiter CI-Knoten.
• Ein aktiver Runner beweist weder eine funktionierende Xcode-Auswahl noch eine gültige Signaturkette.

Die häufigste Fehlannahme lautet: „Der Mac ist nach dem Neustart online, also ist die Wartung erfolgreich.“ Für produktive CI zählt jedoch die gesamte Kette: Host, Runner, Xcode-Aufruf, Abhängigkeiten, Build, Signatur, Upload und Protokollierung.

Für normale Pull-Request-Builds ist ein entleerter Knotenpool der sicherste Einstieg. Sie verhindern zunächst neue Zuweisungen, lassen laufende Jobs bis zum definierten Ende arbeiten und markieren den Knoten erst danach als wartungsbereit.

Entleerung und Zustandsprüfung

Prüfen Sie vor jeder Änderung mindestens diese Zustände:

• Runner nimmt keine neuen Jobs mehr an.
• Bereits gestartete Jobs sind abgeschlossen oder anhand einer dokumentierten Regel beendet.
• Der Knoten ist dem richtigen Pool und den richtigen Labels zugeordnet.
• Die bisherige macOS-Version und der Xcode-Pfad sind protokolliert.
• Der Knoten kann nach dem Neustart über den vorgesehenen Fernzugang erreicht werden.
• Ein anderer Knoten kann die erwartete Arbeitslast übernehmen.

Die Änderung sollte nicht nur im MDM- oder Verwaltungsprotokoll stehen. Sichern Sie zusätzlich den CI-Zustand, den Zeitpunkt des letzten Jobs und die bisher erfolgreiche Referenzpipeline. Dadurch lässt sich später unterscheiden, ob ein Fehler durch das Betriebssystem, den Runner, Xcode oder eine Abhängigkeit ausgelöst wurde.

Pilotknoten und erste Abnahme

Wählen Sie einen Knoten, dessen Ausfall keine Release-Aufgabe blockiert. Aktualisieren Sie ihn nicht gleichzeitig mit einem Signierknoten. Nach dem Neustart prüfen Sie zuerst den Host und danach den Runner. Erst wenn beide verfügbar sind, starten Sie die fachliche Abnahme.

Die erste Pipeline sollte nicht nur einen kurzen Statuscheck enthalten. Sie muss den realen Pfad des Teams abbilden:

1. Repository auschecken.
2. Abhängigkeiten mit dem im Projekt freigegebenen Verfahren auflösen.
3. Xcode explizit über den erwarteten Pfad aufrufen.
4. Einen sauberen Build ohne wiederverwendete Artefakte ausführen.
5. Tests und gegebenenfalls Simulator- oder Geräteprüfungen durchführen.
6. Build-Logs und verwendete Toolchain archivieren.

Die Apple-Dokumentation zu deklarativen Softwareupdate-Konfigurationen beschreibt, wie Updates in verwalteten Umgebungen gesteuert werden können. Sie ersetzt jedoch nicht den Nachweis, dass Ihr konkreter Runner nach dem Neustart automatisch startet und Jobs korrekt annimmt.

Rollout-Nachweis

Ein Knoten wird erst dann für die nächste Gruppe freigegeben, wenn drei Nachweise zusammenpassen:

Führen Sie diese Prüfung für jede Gruppe aus. Ein globaler „Update erfolgreich“-Status ist nicht ausreichend, weil er nur die Softwareverteilung und nicht den CI-Betrieb abbilden kann.

Signierknoten brauchen einen eigenen Wartungsrhythmus. Ein fehlgeschlagener Pull-Request-Build verzögert eine Prüfung. Ein unterbrochener Archivierungs-, Signier- oder Upload-Vorgang kann dagegen ein geplantes Release blockieren und eine schwer nachvollziehbare Wiederholung erzeugen.

Vor dem Wartungsfenster frieren Sie Release-Aufgaben ein. Danach prüfen Sie die Grenze des Rückfallverfahrens:

• Welche Jobs dürfen während des Fensters überhaupt starten?
• Welcher Knoten besitzt die freigegebenen Zertifikate und privaten Schlüssel?
• Ist der benötigte Keychain-Zustand dokumentiert?
• Sind App-Store-Connect-Zugangsdaten oder vergleichbare Upload-Berechtigungen verfügbar?
• Welche Artefakte dürfen erneut signiert werden?
• Welcher nicht aktualisierte oder temporär bereitgestellte Knoten übernimmt bei einem Fehlschlag?

Die Aktualisierung darf nicht als erfolgreich gelten, nur weil der Runner wieder online ist. Die Abnahme muss die komplette Produktionskette enthalten:

Bewahren Sie private Schlüssel nicht als einfache Kopie in einem temporären Remote-System auf. Wenn ein gemieteter Knoten als Ausweichkapazität dient, müssen Sie vorab klären, welche Geheimnisse dort verwendet werden dürfen, wie sie isoliert werden und wie sie nach dem Wartungsfenster entfernt oder gesperrt werden.

Bei Apple-Silicon-Knoten ist die Update-Autorisierung ein eigener Prüffall. Apple beschreibt die Beziehungen zwischen Bootstrap Token, Secure Token, Volume Ownership und der Möglichkeit, Softwareupdates auf verwalteten Geräten auszuführen. Die Dokumentation zu Update-Autorisierung und Volume Ownership bestätigt jedoch nicht, dass jede Verwaltungsplattform alle Funktionen gleich implementiert oder den Status zuverlässig an Ihre CI-Steuerung zurückmeldet.

Planen Sie deshalb einen kontrollierten Neustarttest vor dem produktiven Upgrade. Der Test muss ohne lokale Bedienung funktionieren und mindestens diese Zustände abdecken:

• FileVault kann im vorgesehenen Betriebsmodell entsperrt werden.
• Der Mac erreicht nach dem Neustart das Netzwerk.
• Die Verwaltung meldet den erwarteten Gerätezustand zurück.
• Der CI-Agent startet automatisch und authentifiziert sich.
• Der Remote-Management-Kanal ist wieder erreichbar.
• Der Knoten nimmt erst nach der technischen und fachlichen Prüfung neue Jobs an.

Remote-Wiederherstellung als eigene Abnahme

Ein vorhandener Bootstrap Token ist kein Beweis für einen erfolgreichen unbeaufsichtigten Ablauf. Ebenso beweist ein gestarteter Benutzerprozess nicht, dass der Agent mit den richtigen Umgebungsvariablen und Zugriffen läuft.

Dokumentieren Sie daher den Ablauf als Betriebsübung:

1. Knoten aus dem CI-Routing entfernen.
2. Ausstehende Jobs prüfen und den Zustand speichern.
3. Update nach der freigegebenen Richtlinie auslösen.
4. Neustart ohne lokale Interaktion abwarten.
5. FileVault-, Netzwerk- und Verwaltungsstatus prüfen.
6. Runner und Xcode-Aufruf kontrollieren.
7. Eine echte, saubere Referenzpipeline ausführen.
8. Erst danach den Knoten wieder in den Pool aufnehmen.

Apple unterscheidet in seiner Dokumentation zu erzwungenen Softwareupdates zwischen Updatebereitstellung und den Bedingungen für Neustarts. Lesen Sie die konkrete Plattformdokumentation deshalb zusammen mit den Unternehmensrichtlinien. Eine allgemeine Apple-Funktion darf nicht ungeprüft als garantiertes Wiederanlaufverhalten Ihres CI-Systems behandelt werden.

Bei mehreren Standorten darf der Wartungszeitpunkt nicht nur nach lokaler Uhrzeit gewählt werden. Sie müssen berücksichtigen, welche Queue, welche Release-Aufgabe und welcher Signierknoten überregional gemeinsam genutzt werden.

Teilen Sie Ihre Topologie in mindestens diese Betriebsgruppen:

Eine pauschale Prozentzahl für die notwendige Reservekapazität ist nicht seriös. Sie hängt von Ihrer maximalen parallelen Jobzahl, der erlaubten Wartezeit, der Wartungsdauer aus Unternehmensaufzeichnungen und dem Anteil nicht verschiebbarer Signierjobs ab. Ermitteln Sie die Reserve aus diesen Betriebsdaten:

Verfügbare Reserve während der Wartung = aktive Knoten außerhalb der Wartungsgruppe − erwartete parallele Jobs.

Ist das Ergebnis negativ, haben Sie keine belastbare Rolling-Upgrade-Kapazität. Dann müssen Sie entweder die Wartungsgruppe verkleinern, Wartungsfenster trennen, die Queue bewusst begrenzen oder vorübergehend zusätzliche Mac-Kapazität bereitstellen.

Ein Remote Mac von CALMVPS kann in diesem Fall als zeitlich begrenzter Build-Knoten für Wartungsspitzen oder als Rückfallressource geprüft werden. Er sollte nicht ohne vorherige Pipeline-, Signatur- und Wiederanlaufprüfung automatisch den produktiven Signierknoten ersetzen.

Bei einer kritischen Sicherheitslücke ist „immer sofort installieren“ genauso unpräzise wie „niemals während eines Release-Zyklus aktualisieren“. Entscheiden Sie anhand von vier Fragen:

• Wie dringend ist die Sicherheitsmaßnahme für die betroffenen Systeme?
• Welche Produktionsaufgaben würden durch einen Neustart unterbrochen?
• Ist die verwendete Xcode- und Abhängigkeitskette bereits mit dem Update geprüft?
• Können Sie auf einen sauberen, nicht betroffenen Knoten zurückfallen?

Die Apple-Dokumentation zu Hintergrund-Sicherheitsupdates hilft bei der Einordnung automatisierter Sicherheitsmechanismen. Sie liefert aber keinen universellen Freigabewert für Ihre CI-Pipeline.

Nutzen Sie diese Bedingungsliste:

• Wenn die Sicherheitsgefahr hoch ist, ein Pilotknoten erfolgreich geprüft wurde und ein funktionsfähiger Rückfallknoten existiert, dann beschleunigen Sie den Rollout in kleinen Gruppen.
• Wenn die Sicherheitsgefahr hoch ist, aber kein Ersatzknoten verfügbar ist, dann aktualisieren Sie zuerst einen isolierten Knoten und begrenzen dessen Aufgaben auf eine geprüfte Pipeline.
• Wenn die Xcode-Kompatibilität ungeklärt ist und kein dringender Sicherheitsschutz erforderlich ist, dann pausieren Sie die breite Installation bis zur Toolchain-Prüfung.
• Wenn die Update-Autorisierung oder der FileVault-Wiederanlauf nicht nachgewiesen ist, dann nehmen Sie den Knoten nicht in eine unbeaufsichtigte Produktionswartung.
• Wenn ein Knoten nach dem Neustart zwar online ist, aber Runner, Xcode-Aufruf oder Signaturprüfung scheitern, dann bleibt er außerhalb des Routings und Sie wechseln auf den sauberen Rückfallknoten.

Wartungs-Checkliste

[ ] Xcode-27-Systemanforderung für jede betroffene Pipeline geprüft
[ ] Unterschied zwischen Sicherheitsupdate, regulärem Update und Versionswechsel dokumentiert
[ ] Pilotknoten ausgewählt und aus dem Release-Pool ausgeschlossen
[ ] Runner vor dem Update für neue Jobs gesperrt
[ ] Laufende Jobs abgeschlossen oder kontrolliert beendet
[ ] macOS-, Xcode- und Abhängigkeitsstände vor dem Upgrade gespeichert
[ ] FileVault-, Bootstrap-Token- und Remote-Wiederanlauf geprüft
[ ] Saubere Referenzpipeline nach dem Neustart ausgeführt
[ ] Archivierung, Codesignatur und Upload separat getestet
[ ] Routing auf noch nicht gewartete Knoten vorbereitet
[ ] Queue-Grenze bei fehlender Reserve festgelegt
[ ] Rückfallknoten oder temporärer Remote Mac vorab geprüft
[ ] Wartungsentscheidung, Logs und Freigabe im Audit abgelegt

Wenn Ihr bestehender Pool genügend unabhängige Kapazität besitzt, ist ein stufenweises macOS-26.6-CI-Upgrade meist kontrollierbarer als eine gleichzeitige Aktualisierung. Wenn alle Knoten dieselbe Wartungszeit benötigen, kein Rückfallknoten existiert oder Signieraufgaben nicht verschoben werden können, fehlt Ihnen nicht nur ein Updateplan, sondern Redundanz.

Der Kauf zusätzlicher Mac-Hardware kann für dauerhaft hohe Last, spezielle physische Schnittstellen oder langfristig stabile Signierprozesse sinnvoll sein. Er bringt jedoch Beschaffung, Abschreibung, Ersatzteilplanung, Vor-Ort-Zugriff und eigene Wartungsfenster mit. Eine improvisierte lokale Ersatzmaschine löst außerdem nicht automatisch FileVault-, Geheimnis- und Auditfragen.

Für ein begrenztes Wartungsfenster ist ein gemieteter Remote Mac oft die passendere Ergänzung: Sie können eine zusätzliche Apple-Silicon-Umgebung für einen PoC, eine reale Abnahmepipeline oder die Überbrückung eines entleerten Pools bereitstellen. Prüfen Sie vorab die verfügbaren CALMVPS-Mietoptionen, die Zugriffsart, die benötigten Berechtigungen und die Entfernung sensibler Daten nach dem Einsatz. Das ersetzt keine langfristige Kapazitätsplanung, verhindert aber, dass ein fehlender Ersatzknoten ein vollständig getestetes Upgrade in einen Produktionsstillstand verwandelt.

Planen Sie das macOS-26.6-CI-Upgrade daher nicht als einzelnen Installationsbefehl. Behandeln Sie es als Betriebsentscheidung mit klarer Trennung zwischen Build-, Signier-, unbeaufsichtigten und regionalen Szenarien. Sobald jede Gruppe eine echte Pipeline, einen dokumentierten Rückfall und einen nachvollziehbaren Wiederanlauf besitzt, können Sie den Rollout verantworten.