Azure Pipelines macOS-14-Abschaltung: Migration 2026 – wie wählen?

Die offizielle Planung sieht für das macOS-14-Image im Oktober 2026 eine Brownout-Phase und am 02.11.2026 die Entfernung vor (Microsofts Zeitplan für Hosted Agents). Der Gewinner ist deshalb nicht „macOS-latest“ für alle Jobs, sondern eine Aufteilung: Zustandslose PR-Builds wechseln nach erfolgreichem Doppeltest auf ein unterstütztes Managed Image; feste Xcode-Versionen, private Netze und Produktionssignaturen laufen auf einem selbstverwalteten Mac. Bis zur Abschaltung bleibt ein zweigleisiger Pool mit dokumentiertem Rückweg die sicherere Entscheidung.

Diese Analyse richtet sich an Verantwortliche, die noch macOS-14 verwenden und ihre Pipelines vor dem Entfernen migrieren müssen. Sie hilft außerdem bei der Auswahl zwischen Microsoft-hosted Agent, einem nach Bedarf bereitgestellten Mac und einem selbstverwalteten Apple-Silicon-Knoten.

macOS-14-Abschaltung nach Aufgaben statt nach Image-Tag bewerten

Eine heute erfolgreiche Pipeline ist kein Nachweis für eine sichere Migration. Ein Brownout kann absichtlich einzelne Jobs aufbrechen, obwohl der YAML-Code am Vortag unverändert war. Deshalb sollte die Azure-Pipelines-macOS-14-Abschaltung als Inventar- und Freigabeprozess behandelt werden, nicht als bloße Änderung von vmImage.

Die erste Bestandsaufnahme erfasst pro Pipeline:

• den verwendeten vmImage-Wert;
• die tatsächlich ausgewählte Xcode-Version;
• benötigte Simulator-Runtimes;
• SDK- und Package-Abhängigkeiten;
• Build-, Test-, Archivierungs- und Veröffentlichungsaufgaben;
• private Git- oder Artefaktquellen;
• Zertifikate, Provisioning Profiles und Keychain-Zugriffe;
• verantwortliches Team und technische Sperren;
• zulässigen Rückfallpfad.

Dabei müssen zwei Fehlerklassen getrennt werden. Ein Image-Entfernungsrisiko entsteht, wenn ein Job noch ausdrücklich macos-14 verlangt. Ein gewöhnlicher Buildfehler kann dagegen durch Quellcode, Abhängigkeiten, Tests oder ein abgelaufenes Zertifikat entstehen. Wer beide Ursachen vermischt, migriert möglicherweise auf ein neues Image und verliert dabei die eigentliche Fehlerquelle.

Das offizielle Image-Repository ist für die Prüfung der vorinstallierten Software und verfügbaren Labels maßgeblich. Die dort gepflegten macOS-Listen sollten unmittelbar vor der Freigabe erneut geprüft werden (offizielle Übersicht der Runner-Images). Eine Pipeline darf nicht allein deshalb als kompatibel gelten, weil sich der Agent registriert und der erste Compile-Schritt startet.

Was geschieht nach dem Entfernen von macOS-14?
Ein Job mit festem macos-14-Label kann während der Brownout-Phase planbar fehlschlagen und nach der endgültigen Entfernung nicht mehr auf diesem Image starten. Jobs mit macos-latest können dagegen auf ein anderes unterstütztes Image zeigen, ohne dass die dort installierte Xcode-, SDK- oder Simulator-Kombination der bisherigen Umgebung entspricht. Beides verlangt eine eigene Prüfung.

Ein einfaches Inventar kann zunächst direkt aus dem Repository erstellt werden:

grep -RInE 'vmImage|xcode|simulator|publish|sign|archive' \
  azure-pipelines*.yml .azure-pipelines/ 2>/dev/null

Beispielausgabe:

azure-pipelines.yml:12:    vmImage: macos-14
azure-pipelines.yml:31:  xcodeVersion: 16.4
azure-pipelines.yml:54:  simulatorRuntime: iOS-18
azure-pipelines.yml:89:  task: Xcode
azure-pipelines.yml:112:  task: Publish

Die Ausgabe ist nur der Startpunkt. Entscheidend ist, ob eine Aufgabe reproduzierbar kompiliert, testet, archiviert und signiert.

PR-Builds auf Managed Images: sauberer Start, kontrollierte Rückkehr

Zustandslose Pull-Request-Builds sind die naheliegendsten Kandidaten für ein unterstütztes Managed Image. Dazu zählen häufig:

• Kompilierung ohne lokale Zustände;
• Unit-Tests ohne private Netzwerkverbindung;
• statische Analyse;
• Paketauflösung aus öffentlich erreichbaren Quellen;
• Artefakterzeugung ohne Produktionszertifikat.

Die Migration sollte nicht mit einer globalen Ersetzung von macos-14 durch macos-latest beginnen. Besser ist ein explizites Ziel-Image, sofern es in der zum Prüfzeitpunkt gültigen Liste unterstützt wird. Für macOS-15, macOS-26 und weitere Labels darf der Status nur aus der aktuellen offiziellen Dokumentation abgeleitet werden. Ein Label ist kein Beweis dafür, dass jede erwartete Xcode-Version oder jeder Simulator Runtime vorhanden ist.

Managed Agents haben einen wichtigen Vorteil: Jeder Job startet in einer kontrollierten, neu bereitgestellten Umgebung. Das reduziert Drift zwischen Projekten. Gleichzeitig gehen lokal installierte Werkzeuge, selbst erzeugte Caches und temporäre Simulatorzustände verloren oder müssen innerhalb des Jobs wiederhergestellt werden. Ein Build, der nur wegen eines alten Derived-Data-Verzeichnisses funktioniert, ist kein reproduzierbarer Build.

Für den Vergleich werden derselbe Commit, dieselben Pipeline-Variablen und dieselben Testdaten verwendet. Gemessen werden nicht nur Agent-Start und Compile-Status, sondern:

1. Abhängigkeiten werden vollständig aufgelöst.
2. Der vollständige Compile-Schritt endet erfolgreich.
3. Unit- und relevante Simulator-Tests laufen durch.
4. Das Archiv lässt sich erzeugen.
5. Artefakte sind vollständig und prüfbar.
6. Ein absichtlich ungültiges Zertifikat wird korrekt abgewiesen, sofern die Pipeline Signaturprüfungen enthält.

Soll Azure Pipelines auf macOS-15 oder macOS-26 wechseln?
Die richtige Wahl ist das Image, das den aktuellen Toolchain-Bedarf mit der geringsten Änderungsfläche erfüllt. macOS-15 ist nicht automatisch sicherer, wenn das Projekt eine neuere SDK-Kombination verlangt. macOS-26 ist nicht automatisch besser, wenn Abhängigkeiten oder Plugins noch nicht dafür validiert wurden. Beide Optionen müssen gegen die zum Freigabezeitpunkt veröffentlichte Image- und Softwareliste sowie gegen einen Doppelrun geprüft werden.

Die Managed-Variante bleibt sinnvoll, wenn der Job keine private Route, keine dauerhafte Keychain und keine feste Nebenbedingung für eine bestimmte Xcode-Unterversion benötigt. Für Cache-intensive Projekte sollten Cache-Schlüssel an Image, Xcode-Version und Architektur gebunden werden. Sonst kann ein scheinbar schnellerer Job Artefakte aus einer inkompatiblen Umgebung wiederverwenden.

Feste Toolchains: Xcode 27, Simulator und Apple Silicon getrennt prüfen

Die Bezeichnung Xcode 27 darf nicht als automatische Produktionsfreigabe verstanden werden. Die offizielle Xcode-27-Arm64-Dokumentation beschreibt den jeweiligen Image- und Softwarestand, ersetzt aber keine Projektvalidierung (Xcode-27-Arm64-Image-Dokumentation).

Ein Projekt benötigt möglicherweise:

• eine bestimmte Xcode-Unterversion;
• einen historischen SDK-Stand;
• eine konkrete Simulator Runtime;
• ein Plugin mit fester Architektur;
• ein Paket, das nur unter einer bestimmten Toolchain aufgelöst wird;
• ein Build-Skript mit impliziten Pfaden;
• ein Archivierungswerkzeug, dessen Verhalten zwischen Images abweicht.

In diesem Fall ist der Wechsel auf macos-latest keine neutrale Modernisierung. Er kann die Reproduzierbarkeit zerstören, obwohl der Quellcode unverändert bleibt. Die Entscheidung fällt anhand der Abhängigkeitstiefe:

• Niedrige Bindung: PR-Build, öffentliche Pakete, kein Simulator-Spezialfall. Managed Image testen und bevorzugen.
• Mittlere Bindung: feste Xcode-Version oder ältere Runtime. Kurzfristig kompatiblen Pool einrichten und parallel Upgrade planen.
• Hohe Bindung: historisches SDK, nicht portierbares Plugin oder zwingende Produktionssignatur. Selbstverwalteten Mac als kontrollierten Knoten verwenden.

Welche iOS-Aufgaben benötigen einen self-hosted macOS agent?
Ein selbstverwalteter Mac ist angezeigt, wenn die Aufgabe dauerhaft installierte Toolchains, private Netzwerkpfade, kontrollierte Keychains oder einen stabilen Simulatorzustand benötigt. Auch ein Veröffentlichungsschritt mit Produktionszertifikaten sollte nicht neben beliebigen PR-Jobs auf demselben Knoten laufen. Die Entscheidung basiert damit nicht auf „iOS“ allein, sondern auf Zustand, Vertrauen und Zugriffspfad.

Apple Silicon muss ebenfalls als eigene Prüfvariable geführt werden. Ein Microsoft-hosted Image, ein nach Bedarf bereitgestellter Apple-Silicon-Agent und ein selbstverwalteter Apple-Silicon-Mac sind organisatorisch und technisch nicht identisch. Zu dokumentieren sind mindestens:

• native oder übersetzte Ausführung;
• verfügbare Xcode- und Simulator-Kombination;
• Image- beziehungsweise Betriebssystemstatus;
• Installations- und Wartungsverantwortung;
• Wiederherstellung nach Neustart;
• Rückfall auf einen bekannten Knoten.

Xcode 27 oder ein neues Arm64-Image kann für Kompatibilitätstests sinnvoll sein. Ein Produktionswechsel ist erst vertretbar, wenn derselbe reale Projektstand kompiliert, testet, archiviert und veröffentlicht wurde. Eine reine Agent-Registrierung liefert dafür zu wenig Beweiskraft.

Private Abhängigkeiten und Signaturaufgaben aus dem allgemeinen Pool lösen

Ein interner Git-Server, ein privates Artefakt-Repository oder ein fester Ausgangspunkt verändert die Architektur sofort. Ein Managed Agent kann den erforderlichen Netzpfad möglicherweise nicht erreichen. Selbst wenn die Verbindung technisch funktioniert, müssen Datenschutz, Ausführungsidentität, Protokollierung und Datenabfluss bewertet werden.

Produktionssignaturen verschärfen die Trennung. Ein Build-Pool für PRs sollte nicht gleichzeitig Zugriff auf Produktionszertifikate und Veröffentlichungsrechte besitzen. Sinnvoll ist eine Aufteilung in:

• öffentlichen oder allgemeinen Build-Pool: Kompilierung, Unit-Tests, statische Prüfungen;
• privaten Toolchain-Pool: feste Xcode-Version, interne Abhängigkeiten, geschützte Artefakte;
• vertrauenswürdigen Signatur-Pool: Archivierung, Produktionssignatur und Veröffentlichung;
• Reserveknoten: Wiederanlauf bei Wartung oder Agent-Ausfall.

Der Signatur-Pool erhält nur die notwendigen Agent-Pool- und Pipeline-Berechtigungen. Das Ausführungsprofil darf keine unnötigen Projekt- oder Repository-Rechte besitzen. Ein gemeinsam genutzter Knoten für mehrere unabhängige Projekte ist besonders kritisch, wenn temporäre Dateien, Simulatordaten oder Credentials nach einem Job verbleiben können.

Die offiziellen Sicherheitshinweise für Pipelines sollten zusammen mit den Agent-Regeln umgesetzt werden. Für macOS-spezifische Agenten beschreibt die Dokumentation zur Absicherung von macOS Agents zusätzliche Anforderungen an Benutzer, Prozesse und Zugriffsschutz.

Hinweis: Eine Pipeline gilt erst dann als isoliert, wenn der Daten- und Berechtigungsfluss nachvollziehbar ist. Zeichnen Sie den Weg von Repository über Build-Knoten und Keychain bis zum Veröffentlichungsziel auf. Prüfen Sie anschließend, ob jeder Pfeil technisch und organisatorisch begrenzt ist.

Für jeden geschützten Job sollte ein Nachweis vorliegen:

• welcher Agent-Pool ausgewählt wird;
• welches Konto den Prozess startet;
• welche Secrets verfügbar sind;
• ob private Endpunkte erreichbar sind;
• ob Zertifikate nach dem Job gesperrt oder entfernt werden;
• welche Pipeline diesen Knoten auslösen darf;
• wie ein kompromittierter Agent aus dem Pool genommen wird.

Die offizielle Agent-Dokumentation zu Sicherheit und Ausführung ist dafür die Referenz. Sie ersetzt jedoch keine unternehmensinterne Rechteprüfung.

Doppelbetrieb bis zur echten Freigabe

Die Migration sollte mit einem begrenzten Proof of Concept beginnen: eine reale PR-Pipeline und eine reale Produktions- oder Staging-Veröffentlichung. Beide laufen zunächst auf macOS-14 und auf dem vorgesehenen Zielknoten. Erfasst werden Commit, Image, Xcode, Architektur, Simulator, Abhängigkeitsquelle, Testergebnis, Archiv-Hash und Signaturprüfung.

Die sieben praktischen Schritte lauten:

1. YAML und Pipeline-Variablen inventarisieren. Feste Images, Xcode-Auswahl, Simulatoren, Veröffentlichungsaufgaben und private Endpunkte markieren.
2. Aufgaben klassifizieren. Zustandslose PR-Arbeit von fester Toolchain, privatem Netzwerk und Produktionstrust trennen.
3. Zielknoten definieren. Für jede Klasse Managed Image, selbstverwalteten Mac oder getrennten Signatur-Pool festlegen.
4. Doppelrun ausführen. Derselbe Commit läuft ohne manuelle Änderungen in beiden Umgebungen.
5. Artefakte und Signaturen vergleichen. Nicht nur Exit-Codes, sondern Archiv, Tests, Paketauflösung und Veröffentlichungsnachweis prüfen.
6. Fehler und Rückweg dokumentieren. Ein fehlgeschlagener Zielrun bleibt auf dem bisherigen Pfad, bis die Ursache behoben ist.
7. Brownout-Fenster beobachten und erst danach abschalten. Nach einer stabilen Beobachtungsphase wird das alte Label aus dem produktiven YAML entfernt.

Eine Anleitung zur Azure-Pipelines-Konfiguration für selbstverwaltete macOS Agents ist dabei nur ein technischer Baustein. Die zentrale Abnahme bleibt der reale Projektlauf.

Für die organisatorische Planung können ein Mietkostenvergleich für Mac-Ressourcen und die Übersicht von SFTPMAC für Remote-Mac-Umgebungen als Ausgangspunkt für eine Beschaffungsprüfung dienen. Das ersetzt keine unternehmensspezifische TCO-Rechnung: Neben Mietkosten gehören Administration, Ausfallreserve, Zertifikatsverwaltung, Wiederherstellung und interne Betriebszeit in das Modell.

Entscheidungsmatrix für Managed, selbstverwaltet und hybrid

Die folgende Matrix trennt die Szenarien, die in der Praxis häufig fälschlich auf ein einziges Image reduziert werden:

Damit beantwortet sich auch die Frage nach dem Mischbetrieb: Managed Agents übernehmen die austauschbaren Jobs; selbstverwaltete Macs übernehmen kontrollbedürftige Aufgaben. Der Agent Pool darf diese Klassen nicht nur logisch benennen, sondern muss sie mit Berechtigungen und Pipeline-Regeln durchsetzen.

Für die Abschlussfreigabe eignet sich folgende kompakte Prüfliste:

Empfehlung für die Migration 2026

Die belastbare Reihenfolge lautet: erst inventarisieren, dann nach Szenario aufteilen, anschließend mit demselben Commit doppelt bauen und erst nach der Abnahme das alte Image entfernen. Ein globales macos-14-zu-macos-latest-Ersetzen ignoriert Xcode-Version, Simulator Runtime, Architektur, private Abhängigkeiten und Signaturrechte.

Für die meisten Unternehmen ist ein Hybridpool die vernünftige Übergangslösung. Er hält standardisierte PR-Arbeit flexibel und schützt gleichzeitig die Aufgaben, bei denen Umgebungskontrolle oder Geheimnisverwaltung wichtiger sind als maximale Austauschbarkeit. Die konkreten Ziel-Labels und der Status von macOS-15, macOS-26, Apple Silicon und Xcode 27 müssen vor dem Rollout erneut anhand der offiziellen Listen geprüft werden.

Wer eine bestehende Hardware- oder Cloud-Umgebung für einen begrenzten PoC erweitern muss, sollte zunächst eine reale PR- und eine reale Veröffentlichungs-Pipeline auf einem dedizierten Remote-Mac-Knoten testen. Gegenüber einer kurzfristig umgewidmeten Entwickler-Maschine entfallen dabei typische Probleme wie wechselnde Benutzerzustände, fehlende Betriebszeiten und unklare Verantwortlichkeit. Gegenüber einem allgemeinen Managed Agent bleiben feste Toolchains, private Netzwerkpfade und kontrollierte Signaturprozesse besser abgrenzbar. Eine zeitgebundene Mac-Miete von SFTPMAC ist deshalb vor allem dann sinnvoll, wenn ein dedizierter Test- oder Reserveknoten benötigt wird, ohne sofort zusätzliche Hardware zu kaufen.

Vor der endgültigen Abschaltung sollte die Freigabe an drei Bedingungen geknüpft werden: der Doppelrun besteht mit dem realen Projekt, der Signatur- und Berechtigungsfluss ist dokumentiert, und ein Wiederanlauf auf dem vorgesehenen Ersatzknoten wurde praktisch geprüft. Erst dann wird aus einer Image-Änderung eine kontrollierte Migration.