Jenkins Mac-Buildknoten-Abnahme: Checkliste 2026

Ein Knoten durchläuft mindestens drei unterschiedliche Zustände:

1. Verbindung erfolgreich: Der Jenkins Agent kann sich beim Controller anmelden und bleibt sichtbar.
2. Technischer Build erfolgreich: Ein festgelegter Build läuft auf dem vorgesehenen Mac durch.
3. Produktionsfähig: Die reale Pipeline funktioniert unter den vereinbarten Sicherheits-, Last- und Wiederanlaufbedingungen.

Nur der dritte Zustand rechtfertigt eine Freigabe für produktive iOS CI/CD-Aufgaben. Jenkins beschreibt Agents als Prozesse, die Aufgaben für den Controller ausführen, und weist zugleich darauf hin, dass Agents als unzuverlässig betrachtet werden müssen. Ein Agent-Status ist deshalb ein Betriebsindikator, kein vollständiger Verfügbarkeitsnachweis. Weitere Einzelheiten enthält die Jenkins-Dokumentation zur Verwaltung von Nodes und Agents.

Für jede Prüfung sollte ein Abnahmeprotokoll geführt werden. Es enthält mindestens:

• Prüfobjekt: beispielsweise Label, Xcode-Version, Keychain oder Workspace.
• Ausgeführte Aktion: der konkrete Pipeline-Schritt oder das Recovery-Szenario.
• Erwartetes Ergebnis: eine prüfbare Bedingung statt einer allgemeinen Aussage.
• Originalnachweis: Console-Log, Konfigurations-Export, Screenshot, Systemprotokoll oder Messreihe.
• Fehlerbehandlung: Verantwortlicher, Frist und Entscheidung über die Freigabe.
• Referenzlauf: Commit, Pipeline-Version und Konfiguration, mit denen der Test wiederholbar ist.

Ein Beispielprojekt ohne echte Abhängigkeiten, Signaturprofile und Release-Schritte ist für diese Entscheidung nicht ausreichend. Die Abnahme muss mit dem Projekt erfolgen, das später tatsächlich gebaut, signiert und veröffentlicht wird.

Der Controller darf nicht als regulärer Produktions-Buildknoten verwendet werden. Jenkins empfiehlt, Builds auf separaten Agents auszuführen; für den integrierten Knoten kann die Zahl der Executors auf null gesetzt werden, damit der Controller Verwaltungs- und Koordinationsaufgaben übernimmt. Diese Trennung dient Sicherheit, Stabilität und Skalierbarkeit.

Prüfen Sie zunächst die technische Verbindung:

• Ist der Agent mit dem vorgesehenen Verbindungsmodus eingerichtet?
• Wird ein kurzzeitiger Netzwerkverlust erkannt und sauber behandelt?
• Wird nach einer Unterbrechung eine neue Verbindung aufgebaut, ohne alte Build-Prozesse unkontrolliert fortzuführen?
• Stimmen Node-Name, Labels, Arbeitsverzeichnis und Betriebssystemarchitektur?
• Sind Disk Space, temporärer Speicher, Uhrzeit-Synchronisierung und Antwortzeit im Monitoring enthalten?

Jenkins überwacht bei Nodes unter anderem freien Speicher, temporären Speicher, Swap, Uhrzeit beziehungsweise Synchronisierung und Antwortzeit. Diese Überwachung ist für eine Abnahme wichtig, weil ein Knoten nicht nur wegen eines ausgefallenen Prozesses unbrauchbar werden kann. Auch ein voller temporärer Bereich oder eine unbrauchbare Arbeitsumgebung kann einen Build blockieren.

Wie wird ein iOS-Build fest an den richtigen Mac-Knoten gebunden?
Legen Sie ein eindeutiges Label für die fachliche Eigenschaft des Nodes fest, beispielsweise für Apple Silicon, eine freigegebene Xcode-Toolchain oder eine isolierte Signaturumgebung. Im Jenkinsfile muss der betreffende Stage dieses Label ausdrücklich anfordern. Die Pipeline-Syntax unterstützt Labels auf Pipeline- und Stage-Ebene; dadurch kann ein einzelner Stage gezielt auf einem passenden Agent ausgeführt werden. Die offizielle Jenkins-Pipeline-Syntax beschreibt diese Zuordnung.

Ein vereinfachtes Muster sieht so aus:

pipeline {
    agent none

    stages {
        stage('iOS Build') {
            agent {
                label 'macos-apple-silicon-release'
            }

            steps {
                sh 'xcodebuild -scheme App -destination generic/platform=iOS archive'
            }
        }
    }
}

Für die Abnahme genügt es nicht, dass das Label im Jenkinsfile steht. Im Pipeline-Log muss nachvollziehbar sein, welcher Node den Stage tatsächlich ausgeführt hat. Prüfen Sie außerdem, dass ein iOS-Job nicht auf einen Knoten ohne passende Xcode-Installation oder auf eine unzulässige Architektur ausweichen kann.

Der Jenkins Agent muss nicht nur Java ausführen und Befehle entgegennehmen. Auf dem Mac liegen die relevanten Buildwerkzeuge, SDKs, Simulatoren, Zertifikate, Paket-Caches und projektspezifischen Skripte. Die Prüfung muss daher die tatsächliche Toolchain abbilden.

Verwenden Sie mindestens diese drei Durchläufe:

1. Sauberer Workspace: Neuer Checkout ohne vorhandene DerivedData und ohne lokale Paket-Caches.
2. Cache-Wiederholung: Derselbe Commit mit den vorgesehenen Caches.
3. Cache-Bereinigung: Caches löschen oder gezielt deaktivieren und den Build erneut ausführen.

Bewahren Sie dabei die vollständigen xcodebuild-Logs, die Lock-Dateien der Abhängigkeiten und die Pipeline-Konfiguration auf. Apple beschreibt für CI-Workflows mit Swift Packages, dass xcodebuild die Git- und SSH-Konfiguration des ausführenden macOS-Benutzers berücksichtigen kann. Die Datei known_hosts, SSH-Schlüssel und gegebenenfalls die Nutzung des System-Git müssen deshalb im tatsächlichen Agent-Kontext geprüft werden. Die Apple-Dokumentation zu Swift Packages und CI-Workflows beschreibt diese Zusammenhänge.

Die Abnahme sollte mindestens folgende Punkte beantworten:

• Wird die erwartete Xcode-Installation verwendet?
• Sind Command Line Tools und SDKs passend zum Projekt vorhanden?
• Werden Swift Package Manager, CocoaPods oder andere Abhängigkeiten reproduzierbar aufgelöst?
• Sind Build-Skripte frei von impliziten Benutzerpfaden?
• Funktioniert der Build nach einem Neustart des Agent-Prozesses?
• Gibt es eine dokumentierte Freigabe für Toolchain-Updates?
• Kann die bisherige Toolchain parallel weiterbetrieben werden, falls ein Upgrade scheitert?

Welche Prüfungen braucht ein Jenkins Mac Agent vor der Freigabe?
Die operative Antwort lautet: Verbindung, Label, Architektur, Xcode, Abhängigkeiten, Signatur, Parallelität, Wiederanlauf und Last müssen jeweils mit einem Originalnachweis belegt sein. Eine Ausgabe wie xcodebuild -version allein bestätigt nur, dass ein Programm gefunden wurde. Sie beweist nicht, dass das Teamprojekt mit dieser Umgebung archiviert und signiert werden kann.

Bei iOS CI/CD ist die Signaturprüfung ein eigener Sicherheitsbereich. Ein erfolgreicher Compile-Schritt darf nicht automatisch den Zugriff auf Produktionszertifikate und App-Store-Schlüssel eröffnen.

Jenkins speichert Credentials verschlüsselt auf dem Controller und verwendet sie in Pipelines über Credential IDs. Die tatsächliche Reichweite hängt jedoch vom Scope, den Berechtigungen des Jobs und der Art der Einbindung ab. Global hinterlegte Credentials können für mehr Pipelines verfügbar sein als beabsichtigt. Die Jenkins-Dokumentation zur Verwendung von Credentials erläutert die grundlegenden Mechanismen.

Prüfen Sie deshalb:

• Ist jedes Credential nur im erforderlichen Folder-, Job- oder Pipeline-Kontext verfügbar?
• Werden Repository-Zugang, App-Store-Zugang und Signaturmaterial getrennt verwaltet?
• Kann ein normaler Build-Job Produktionszertifikate oder private Schlüssel lesen?
• Wird die temporäre Einbindung nach dem Build entfernt?
• Sind geheime Werte aus Console-Logs, Fehlermeldungen und Artefakten entfernt?
• Ist der macOS-Schlüsselbund für den Jenkins-Benutzer kontrolliert und reproduzierbar entsperrbar?
• Gibt es einen eigenen Node oder Agent-Pool für Produktionssignierung?

Apple weist darauf hin, dass eine Signaturidentität aus Zertifikat und privatem Schlüssel besteht und der private Schlüssel besonders geschützt werden muss. Die Weitergabe an unbefugte Personen oder nicht kontrollierte Systeme gefährdet die Identität. Die Apple-Dokumentation zur Codesignierung sollte deshalb Bestandteil der internen Sicherheitsprüfung sein.

Führen Sie zusätzlich einen absichtlich eingeschränkten Testjob aus. Dieser Job darf nur den Quellcode auschecken und einen nicht signierenden Build ausführen. Er versucht kontrolliert, auf fremde Credentials, nicht zugehörige Keychain-Einträge und Produktionsverzeichnisse zuzugreifen. Der erwartete Zustand ist nicht „Zugriff funktioniert“, sondern „Zugriff wird verweigert und der Vorgang wird protokolliert“.

Achtung: Ein gemeinsamer Mac für Entwicklungs-Builds, Testsignierung und Produktionsfreigaben ist nur vertretbar, wenn die organisatorische und technische Trennung nachweisbar ist. Sobald ein Job fremde Schlüssel lesen, persistente Workspace-Dateien übernehmen oder Prozesse anderer Jobs beeinflussen kann, sollte die Signatur auf einen separaten Agent oder einen eigenen Mac verschoben werden.

Kann ein Jenkins Mac Agent mehrere iOS-Pipelines gleichzeitig ausführen?
Ja, technisch können mehrere Executors parallele Aufgaben ermöglichen. Ob dies für das konkrete Projekt zulässig ist, hängt jedoch von CPU, Arbeitsspeicher, I/O, Netzwerk, Simulatoren, DerivedData, Keychain-Zustand und der Fehlerquote ab. Jenkins bezeichnet einen Executor als Ausführungsplatz und nennt einen Executor pro Node als sichere Konfiguration. Mehrere Executors müssen anhand der realen Arbeitslast überwacht und begründet werden.

Führen Sie keinen Kapazitätstest nur anhand des Chipnamens durch. Stellen Sie stattdessen die reale Spitzenlast nach:

1. Starten Sie die für ein Release-Fenster typische Anzahl an Jobs.
2. Verwenden Sie echte Branches oder reproduzierbare Commits.
3. Messen Sie Wartezeit, Build-Dauer, CPU, Arbeitsspeicher, Speicherplatz und I/O.
4. Beobachten Sie DerivedData, Simulatorzustände und temporäre Verzeichnisse.
5. Prüfen Sie, ob ein Job Dateien, Cache-Einträge oder Keychain-Zustände eines anderen Jobs verändert.
6. Wiederholen Sie den Test mit Cache-Hit und Cache-Miss.
7. Halten Sie Fehlerrate und manuelle Eingriffe getrennt von reiner Wartezeit fest.

Bei einem gemeinsam genutzten Node sollten Workspace-Pfade eindeutig sein. Noch wichtiger ist, dass parallele Jobs keine globalen Zustände verwenden, die nicht für Parallelbetrieb ausgelegt sind. Dazu gehören gemeinsam genutzte DerivedData-Verzeichnisse, feste Simulatornamen, globale Paket-Caches und unkontrolliert entsperrte Schlüsselbunde.

Wie viele Executors braucht ein Jenkins iOS-Buildknoten?
Als Startpunkt ist ein Executor pro Mac die konservative Wahl. Eine Erhöhung ist erst dann vertretbar, wenn die reale Lastprüfung zeigt, dass die akzeptable Warteschlange, die Build-Fehlerquote und die Sicherheitsgrenzen eingehalten werden. Für signierende Release-Jobs kann ein separater Knoten mit nur einem Executor sinnvoller sein als eine höhere Auslastung auf einem gemeinsam genutzten Mac.

Ein erreichbarer Mac ist nicht automatisch ein wiederherstellbarer Mac. Der Wiederanlauf muss als Fehlerdomäne separat geprüft werden.

Führen Sie mindestens diese Szenarien aus:

• geplanter Neustart des Macs,
• manueller Abbruch des Agent-Prozesses,
• kurzzeitige Unterbrechung der Netzwerkverbindung,
• voller oder nahezu voller temporärer Speicher,
• abgelaufene SSH-Verbindung,
• abgebrochener Build mit anschließendem Neuversuch,
• erneute Verbindung des Agents nach einem Neustart.

Dokumentieren Sie für jedes Szenario:

• erkannter Fehler,
• automatische Reaktion,
• notwendige Berechtigung,
• benötigte manuelle Aktion,
• Zustand alter Prozesse,
• Zeitpunkt der Wiederaufnahme,
• Ergebnis eines echten Test-Builds.

Apple unterstützt den Remote Login eines Macs über SSH, sofern Remote Login aktiviert und der Zugriff für die vorgesehenen Benutzer erlaubt ist. Gleichzeitig weist Apple darauf hin, dass Remote Login die Sicherheit beeinflussen kann und deshalb auf einen klar begrenzten Benutzerkreis beschränkt werden sollte. Die Apple-Anleitung zu Remote Login auf dem Mac nennt die dafür relevanten Systemeinstellungen.

Bei Apple Silicon und macOS 26 oder höher beschreibt Apple außerdem das Entsperren von FileVault über SSH nach einem Neustart, wenn Remote Login aktiviert und eine Netzwerkverbindung verfügbar ist. Diese Möglichkeit darf nicht ungeprüft als vollständige Disaster-Recovery-Lösung betrachtet werden: Netzwerk, Secure Token, Schlüsselverwaltung, Boot-Zustand und organisatorische Freigaben müssen im konkreten Umfeld funktionieren. Die Apple-Dokumentation zum FileVault-Entsperren über SSH ist vor der Abnahme gegen die tatsächlich eingesetzte macOS-Version zu prüfen.

Wie wird ein Jenkins Agent nach einem Neustart automatisch wieder aktiv?
Die Abnahme muss zeigen, dass der Agent-Prozess automatisch startet, sich mit dem Controller verbindet, das korrekte Label erhält und einen Testjob ausführen kann. Ein laufender macOS-Prozess allein reicht nicht. Der Nachweis muss bis zur erfolgreichen Pipeline reichen.

Zusätzlich sollte die Wiederherstellung nach einem fehlgeschlagenen Build getestet werden. Wenn ein abgebrochener Prozess einen Simulator, eine Keychain-Sperre oder eine temporäre Datei hinterlässt, muss der nächste Build entweder automatisch bereinigt werden oder kontrolliert blockieren. Ein scheinbar erfolgreicher Wiederanlauf mit kontaminierter Umgebung ist keine bestandene Prüfung.

Die Freigabe sollte nicht als subjektives „fühlt sich stabil an“ formuliert werden. Verwenden Sie vier klar getrennte Ergebnisse:

Freigabe für den Produktivbetrieb

Der Knoten erfüllt alle sechs Prüfbereiche, die reale Pipeline läuft durch, Credentials sind begrenzt, Parallelität ist belegt und der Wiederanlauf wurde mit einem echten Build bestätigt.

Begrenzter Testbetrieb

Die technische Basis funktioniert, aber Kapazität, Wiederanlauf oder Signaturisolierung sind noch nicht ausreichend belegt. Der Node darf nur für nichtkritische Builds oder eine definierte Pilotgruppe eingesetzt werden.

Nachbesserung mit erneuter Abnahme

Ein klar lokalisierter Fehler verhindert die Freigabe, beispielsweise ein falsches Label, eine fehlende Toolchain-Abhängigkeit oder ein nicht reproduzierbarer Keychain-Schritt. Die Freigabe erfolgt erst nach erneuter Prüfung mit demselben Nachweisformat.

Ablehnung

Der Node verletzt eine nicht verhandelbare Sicherheits- oder Betriebsanforderung. Beispiele sind produktive Signaturschlüssel ohne ausreichende Isolation, fehlende Wiederherstellung im Release-Fenster oder eine Kapazität, die schon bei der realistischen Spitzenlast zu unvertretbaren Warteschlangen führt.

Für die Abnahme sollte jeweils ein Verantwortlicher benannt werden: Plattform Engineering für Agent und Scheduling, IT beziehungsweise Security für Zugriff und Credentials, iOS Engineering für Xcode und Signatur sowie der technische Leiter für die endgültige Produktionsfreigabe.

Wie bindet Jenkins iOS-Aufgaben dauerhaft an Mac-Knoten?
Über eindeutige Labels und eine Stage-spezifische agent-Definition. Der Pipeline-Log muss außerdem belegen, dass der gewünschte Node verwendet wurde. Eine freie Auswahl mit agent any ist für architektur- oder Xcodeabhängige Release-Stages ungeeignet.

Darf der Jenkins Controller zusätzlich Builds ausführen?
Für produktive Umgebungen sollte der Controller von regulären Builds getrennt bleiben. Jenkins nennt Sicherheits-, Performance- und Skalierbarkeitsgründe und empfiehlt, das Ausführen von Aufgaben auf dem integrierten Node zu vermeiden.

Wie werden Apple Silicon und Xcode bei der Node-Auswahl berücksichtigt?
Die Eigenschaften sollten über Labels und Abnahmetests abgebildet werden. Die Pipeline muss mit dem realen Projekt prüfen, ob Architektur, Xcode, SDKs, Abhängigkeiten und Signaturpfad gemeinsam funktionieren. Ein Architekturlabel ohne erfolgreichen Archiv- und Signaturtest ist nur Konfiguration, kein Nachweis.

Welche Grenze gilt für gemeinsam genutzte Mac-Buildknoten?
Entwicklungs- und Test-Builds können unter kontrollierten Bedingungen gemeinsam laufen. Produktionssignierung, sensible Projekte und Jobs mit unterschiedlichen Vertrauensstufen sollten getrennt werden, wenn Credentials, Workspace oder Schlüsselbund nicht zuverlässig isoliert werden können.

Wann sollte ein Team die Mac-Kapazität erhöhen?
Nicht beim Überschreiten einer theoretischen CPU-Grenze, sondern wenn die vereinbarte maximale Warteschlange, das Release-Fenster oder die tolerierte Fehlerquote unter realer Last nicht mehr eingehalten wird. Die Entscheidung sollte auf Pipeline-Logs und Systemmetriken beruhen.

Welche Rolle spielt eine remote gemietete Mac-Umgebung bei der Abnahme?
Sie kann als zeitlich begrenzter, unabhängiger Prüf- und Belastungsknoten dienen, wenn dem Team noch keine zusätzliche Hardware für Neustart-, Parallelitäts- und Signaturtests zur Verfügung steht. Dafür sollte zunächst die echte Jenkins Pipeline importiert und die gleiche Evidenz gesammelt werden wie auf einem späteren festen Knoten. Informationen zu verfügbaren Zugangswegen und regionalen Optionen kann die IT-Verantwortung auf der deutschen NUKCLOUD-Übersicht prüfen.

Eine gemietete Umgebung ersetzt nicht automatisch eine langfristige Plattformstrategie. Für dauerhaft hohe, planbare Last, besondere physische Schnittstellen oder streng kontrollierte Hardware-Lebenszyklen kann ein eigener Mac wirtschaftlich und organisatorisch geeigneter sein. Für schwankende Release-Phasen, Pilotprojekte und die Abnahme eines neuen Jenkins Mac-Buildknotens vermeidet ein periodisch nutzbarer Remote-Mac dagegen die sofortige Bindung an eine feste Hardwaremenge.

• [ ] Der Controller führt keine regulären Produktions-Builds aus.
• [ ] Der Jenkins Agent verbindet sich über den freigegebenen Mechanismus.
• [ ] Netzwerkunterbrechung und Wiederverbindung sind getestet.
• [ ] Node-Name, Label, Architektur und Xcode-Zuordnung sind dokumentiert.
• [ ] iOS-Stages werden nicht auf ungeeignete Mac-Knoten verteilt.
• [ ] Disk Space, temporärer Speicher, Uhrzeit und Antwortzeit werden überwacht.
• [ ] Sauberer Build, Cache-Build und Cache-Cleanup-Build sind erfolgreich.
• [ ] Xcode, Command Line Tools, SDKs und Abhängigkeiten sind projektbezogen geprüft.
• [ ] Toolchain-Änderungen haben einen verantwortlichen Freigabeprozess.
• [ ] Repository-Credentials sind auf den notwendigen Scope begrenzt.
• [ ] Produktionszertifikate und private Schlüssel sind von normalen Buildjobs getrennt.
• [ ] Ein Low-Privilege-Test kann keine fremden Secrets oder Keychain-Einträge lesen.
• [ ] Console-Logs und Artefakte enthalten keine geheimen Werte.
• [ ] Der Executor-Wert ist durch einen realen Lasttest begründet.
• [ ] Parallele Jobs verwenden keine unkontrolliert gemeinsamen Workspaces.
• [ ] DerivedData, Simulatoren, temporäre Dateien und Caches werden sicher behandelt.
• [ ] Neustart, Agent-Abbruch und Netzunterbrechung sind reproduzierbar getestet.
• [ ] FileVault- und SSH-Voraussetzungen sind dokumentiert.
• [ ] Ein echter Build läuft nach dem Wiederanlauf erfolgreich durch.
• [ ] Die Entscheidung lautet eindeutig: freigegeben, begrenzter Test, Nachbesserung oder abgelehnt.

Wenn diese Nachweise fehlen, sollte kein dauerhaftes Mac-Budget allein anhand des Status „online“ beschlossen werden. Ein eigener Kauf bindet Kapital, Wartungsaufwand und Kapazität an eine Annahme, die möglicherweise noch nicht belegt ist. Ein periodisch gemieteter Mac von NUKCLOUD kann in dieser Phase als zusätzlicher Prüf- und Lastknoten dienen: erst reale Jenkins-Läufe, Signaturtests und Wiederanlaufprotokolle sammeln, danach feste Nodes, Executor-Anzahl und elastische Kapazität festlegen. Für Vertrags- und Betriebsbedingungen sollte die IT-Abteilung zusätzlich die deutschen Geschäftsbedingungen von NUKCLOUD in den Beschaffungsprozess aufnehmen.