Kann Xcode Cloud auf das Unternehmensintranet zugreifen? 2026 Private-Abhängigkeiten

📋 Inhaltsverzeichnis

Apple beschreibt für Xcode Cloud eine temporäre Build-Umgebung und veröffentlichte Netzwerkvorgaben für die Verbindung zu unterstützten SCM-Systemen. Daraus folgt die entscheidende Grenze: Xcode Cloud Unternehmensintranet-Zugriff ist nicht automatisch ein vollständiger VPN- oder Subnetz-Zugriff. Sie können autorisierte private Repositories und private Abhängigkeiten verwenden, wenn Netzwerkreichweite, Berechtigung und Nutzbarkeit in der Build-Umgebung gleichzeitig erfüllt sind. Bleibt eine Kernabhängigkeit ausschließlich im VPN, hinter einer privaten DNS-Zone oder in einem nicht exponierbaren internen Dienst, gehört dieser Build-Schritt auf einen kontrollierten Remote Mac.

Für wen diese Entscheidung relevant ist: Sie betreiben iOS CI/CD und prüfen Xcode Cloud trotz interner Quellcode- oder Paketserver. Sie verwalten private Swift Packages, Git-Submodule oder interne Artefakt-Dienste. Oder Sie verantworten Firewall-Regeln, Zugangsentzug und die Trennung von Produktionssignaturen und gewöhnlichen Builds.

Die drei Prüfbedingungen für Xcode Cloud im Unternehmensintranet

Der typische Widerspruch sieht so aus: Das SCM-Projekt ist verbunden, der erste Zugriff auf das Repository scheint erfolgreich, aber eine interne Abhängigkeit lässt sich im Build nicht laden. Dieser Befund beweist nur, dass ein bestimmter Zugriff funktioniert hat. Er beweist nicht, dass jede Ressource Ihres Unternehmensnetzes aus der Build-Umgebung erreichbar ist.

Prüfen Sie jede Abhängigkeit anhand von drei Bedingungen:

Netzwerkreichweite: Die Build-Umgebung muss den Zielhost über einen von Apple unterstützten und in Ihrer Firewall erlaubten Weg erreichen können.
Identität und Berechtigung: Der verwendete SCM- oder Dienstzugang muss für genau dieses Repository, Paket oder Artefakt autorisiert sein.
Nutzbarkeit im Build: Die Ressource muss mit den verfügbaren Umgebungsvariablen, Zertifikaten, Werkzeugen und Dateilebenszyklen des temporären Builds funktionieren.

Fehlt eine Bedingung, wählen Sie nicht den nächsten zufälligen Workaround. Ordnen Sie die Ressource einer Ersatzroute zu: kontrollierte HTTPS-Erreichbarkeit, schreibgeschützter Dependency-Mirror, vorgebautes Artefakt oder ein eigener Remote-Mac-Knoten.

Apple beschreibt die Voraussetzungen für SCM-Verbindungen und die dafür relevanten Firewall-Anforderungen in der offiziellen Xcode-Cloud-Dokumentation zu SCM und Netzwerkzugriff. Die dort genannten Adressbereiche sind keine pauschale Erlaubnis für Ihr gesamtes Intranet. Sie müssen vielmehr den konkreten Dienst, die Richtung der Verbindung und die zulässige Identität mit Ihrer Sicherheitsrichtlinie abgleichen.

Vier Ressourcentypen, vier unterschiedliche Risiken

Quellcode-Repository: Ein selbst gehostetes Git-System kann erreichbar sein, wenn es über den geforderten HTTPS-Weg bereitgestellt und korrekt autorisiert wird.
Private Softwarepakete: Ein privates Repository für den Swift Package Manager benötigt zusätzlich eine gültige Abhängigkeitserklärung und eine passende Autorisierung.
Interner Artefakt-Dienst: Ein Paket- oder Binärserver kann an interner DNS-Auflösung, Client-Zertifikaten, festen Ausgangsadressen oder einer VPN-Pflicht scheitern.
VPN-exklusive Ressource: Ein Dienst, der nur nach Einwahl in Ihr Unternehmens-VPN existiert, ist nicht allein deshalb für Xcode Cloud verfügbar, weil ein Entwicklerarbeitsplatz ihn erreicht.

Diese Unterscheidung verhindert einen häufigen Fehlentscheid: Sie testen im Browser mit einem administrativen Konto und schließen daraus, dass der CI-Dienst dieselbe Sichtbarkeit besitzt. Die Build-Umgebung verwendet jedoch nicht automatisch Ihre Browser-Sitzung, Ihre lokale VPN-Verbindung oder Ihre persönlichen SCM-Rechte.

Hinweis: Behandeln Sie eine erfolgreiche Repository-Verbindung als einzelnes Testergebnis, nicht als Nachweis für einen allgemeinen Intranet-Tunnel. Prüfen Sie jede abhängige URL und jeden Authentifizierungsweg separat.

Selbst gehostetes Git und GitHub Enterprise: Netzwerk gegen Berechtigung

Für die Frage, wie Xcode Cloud ein internes Git-Repository erreicht, müssen Sie mindestens vier Ebenen auseinanderhalten:

DNS und Routing: Kann die Build-Umgebung den Hostnamen auflösen und eine Verbindung zum Ziel herstellen?
Firewall: Sind die von Apple veröffentlichten Adressbereiche für den erforderlichen eingehenden Zugriff erlaubt?
SCM-Verknüpfung: Ist die Organisation oder das Projekt mit dem richtigen SCM-Konto verbunden?
Repository-Rechte: Darf genau die verwendete Identität den Code lesen, Untermodule abrufen und gegebenenfalls Tags oder Abhängigkeiten auflösen?

Das gilt auch für GitHub Enterprise. Der Name des SCM-Systems ersetzt keine Netzwerkprüfung. Ein Enterprise-Server kann aus Sicht Ihres Büro-Netzes verfügbar sein, während ein externer Build-Dienst an einer privaten Adresse, einer restriktiven Firewall oder einem nicht öffentlich erreichbaren Zertifikatsweg endet.

Apple nennt für Xcode Cloud unterstützte cloudbasierte und selbst gehostete SCM-Szenarien sowie Anforderungen an die Netzwerkfreigabe. Prüfen Sie die aktuelle Apple-Dokumentation zu SCM und den erforderlichen Firewall-Einstellungen, bevor Sie eine Allowlist anlegen. Übernehmen Sie keine alte Adressliste aus einem internen Ticket, sondern gleichen Sie die Liste direkt mit der Quelle ab.

Symptome, Belege, Zuständigkeit

Der Repository-Test schlägt beim Verbindungsaufbau fehl:
Beleg: DNS-, TLS- oder Firewall-Protokoll des Zielsystems.
Zuständig: Netzwerk- und Plattformteam.
Maßnahme: Erreichbarkeit des konkreten Hosts und die erlaubte Quelle prüfen.
Das Repository ist verbunden, der Build klont aber nicht:
Beleg: Build-Log zusammen mit SCM-Autorisierungsprotokoll.
Zuständig: SCM- und CI-Verantwortliche.
Maßnahme: Organisation, Projektrolle und Leserechte der tatsächlich verwendeten Verbindung prüfen.
Der Hauptcode wird geladen, ein Git-Submodul fehlt:
Beleg: exakte Submodul-URL und Fehlerstelle im Klonvorgang.
Zuständig: Repository-Owner und CI-Team.
Maßnahme: Erreichbarkeit und Berechtigung des Submoduls unabhängig vom Haupt-Repository testen.
Der Administrator kann im Browser zugreifen, der Build nicht:
Beleg: unterschiedliche Identitäten, Header, Zertifikate oder Netzwerkpfade.
Zuständig: IAM- und Sicherheitsteam.
Maßnahme: Browserzugriff nicht als Abnahmekriterium verwenden; ein minimales Test-Repository mit der CI-Verbindung ausführen.

Die sauberste erste Prüfung ist ein kleines, isoliertes Repository. Es sollte nur eine App, eine private Paketabhängigkeit und – falls relevant – ein Submodul enthalten. So sehen Sie, ob der Fehler im Netzwerk, in der SCM-Autorisierung oder in der Abhängigkeitsauflösung entsteht.

Private Swift Packages und Git-Submodule

Xcode Cloud kann private Abhängigkeiten auf unterstützten SCM-Plattformen verwenden, wenn Sie den dafür vorgesehenen Autorisierungsweg einrichten. Das bedeutet nicht, dass jede neue interne Abhängigkeit beim ersten Versuch funktioniert. Besonders häufig scheitert die Pipeline, weil die Abhängigkeit zwar im Hauptprojekt eingetragen ist, aber ihre konkrete URL, Version oder Zugriffserlaubnis nicht zur Build-Identität passt.

Für den Swift Package Manager prüfen Sie diese Punkte:

Ist die URL in der Projektkonfiguration exakt die erwartete SCM-Adresse?
Liegt das Paket auf einer unterstützten und aus der Build-Umgebung erreichbaren Instanz?
Ist die erforderliche Organisation oder das Repository für die verwendete Verbindung freigegeben?
Ist Package.resolved konsistent und auf eine tatsächlich verfügbare Version festgelegt?
Lädt das Paket weitere private Pakete oder Git-Submodule nach?
Wird ein Zertifikat, Token oder SSH-Mechanismus vorausgesetzt, den die Build-Umgebung nicht erhält?

Die Apple-Anleitung für private Abhängigkeiten in Xcode Cloud beschreibt den Autorisierungsweg für unterstützte SCM-Dienste. Ergänzend sollten Sie die Hinweise zum Bauen von Swift Packages und Projekten mit solchen Abhängigkeiten heranziehen.

Eine prüfbare Abhängigkeitsliste

Führen Sie für jede private Ressource einen kleinen Eintrag mit diesen Feldern:

Name und Zweck der Abhängigkeit
Typ: Repository, Swift Package, Submodul oder Artefakt
Exakte URL oder Hostname
SCM-Instanz und verantwortliches Team
Benötigte Leserechte und Authentifizierungsart
Erforderlicher Netzwerkpfad
Erwartete Version aus Package.resolved oder einer anderen Lock-Datei
Build-Schritt, in dem die Ressource verwendet wird
Nachweis: Build-Log, Autorisierungsereignis oder Dienstprotokoll
Rückfallroute bei Nichterreichbarkeit

Unterscheiden Sie im Fehlerbericht mindestens diese drei Fälle:

Versions- oder Auflösungsfehler: Der Dienst ist erreichbar, aber die angeforderte Version oder Abhängigkeitskombination existiert nicht.
Netzwerkfehler: Der Hostname kann nicht aufgelöst werden, TLS scheitert oder die Verbindung wird blockiert.
Authentifizierungsfehler: Die Verbindung kommt zustande, aber die Identität darf das Repository oder Paket nicht lesen.

Diese Klassifizierung verhindert, dass das CI-Team eine Firewall-Ausnahme beantragt, obwohl lediglich Package.resolved veraltet ist. Umgekehrt darf ein erfolgreich aufgelöstes Paket nicht als Beweis gelten, dass ein interner Artefaktserver im späteren Release-Schritt erreichbar bleibt.

Benutzerdefinierte Skripte und temporäre Build-Umgebungen

Benutzerdefinierte Xcode-Cloud-Skripte können fehlende Werkzeuge installieren, externe Dienste aufrufen und Geheimnisse über vorgesehene Umgebungsvariablen verwenden. Sie schaffen jedoch keinen dauerhaften Serverzustand und ersetzen keinen privaten Netzwerkzugang. Apple weist außerdem auf Einschränkungen der Build-Umgebung hin; insbesondere können Sie nicht einfach mit sudo dauerhafte Maschinenkonfigurationen erzwingen. Die relevanten Grenzen beschreibt die Apple-Dokumentation zu benutzerdefinierten Build-Skripten.

Ein minimales ci_post_clone.sh sollte deshalb nur die für den Build zwingenden Vorbereitungen erledigen:

#!/bin/sh
set -e

./ci/verify-private-dependencies.sh
./ci/install-required-tools.sh
./ci/run-build-preflight.sh

Die drei Skripte stehen hier für klar getrennte Prüfungen. Das erste validiert die erwarteten Abhängigkeiten, das zweite installiert nur reproduzierbare Werkzeuge aus einer freigegebenen Quelle, und das dritte beendet den Build frühzeitig, wenn eine notwendige Variable oder Datei fehlt. Vermeiden Sie es, in diesem Hook einen langfristigen Cache, eine lokale Benutzerkonfiguration oder eine geheime Maschinenidentität aufzubauen.

Prüfen Sie bei jedem Skript:

Ist die Installationsquelle versioniert und intern freigegeben?
Wird ein Geheimnis nur über den vorgesehenen Variablenmechanismus eingelesen?
Wird der Wert niemals in Build-Logs ausgegeben?
Werden temporäre Dateien nach dem Gebrauch entfernt oder zumindest nicht als dauerhaft vorausgesetzt?
Liefert jeder kritische Fehler einen ungleich nullen Exit-Code?
Funktioniert der nächste Build auf einer frischen Umgebung?

Die Apple-Referenz zu Umgebungsvariablen in Xcode Cloud hilft bei der Abgrenzung der verfügbaren Variablen. Für Sicherheitsfragen sollten Sie zusätzlich Apples Beschreibung der Sicherheitsarchitektur von Xcode Cloud lesen. Ein Skript, das einen Netzwerkbefehl ausführen kann, beweist nicht, dass der Zielservice aus diesem Netzwerkpfad erreichbar ist.

Erfahrungsregel: Wenn Ihr Build nur nach einer manuellen Änderung auf einem bestimmten Rechner funktioniert, ist das kein geeigneter Xcode-Cloud-Mechanismus. Verschieben Sie die Voraussetzung in eine reproduzierbare Abhängigkeit oder auf einen kontrollierten Knoten.

VPN, interne Artefakte und echte Architekturgrenzen

Die schwierigsten Fälle sind nicht private Git-Repositories, sondern Dienste mit einer festen internen Vertrauenszone. Prüfen Sie besonders kritisch:

interne DNS-Namen ohne öffentlich oder kontrolliert auflösbaren Gegenpart,
Dienste, die ausschließlich nach VPN-Einwahl antworten,
gegenseitige TLS-Zertifikate mit organisationsgebundener Identität,
Allowlisten, die nur bestimmte feste Ausgangswege akzeptieren,
Artefakte, die nur mit einem dauerhaft warmen Cache verfügbar sind,
Produktionsdienste, die keinen externen Zugriff erlauben dürfen.

Apple bestätigt in den genannten Dokumentationsseiten die Verbindung zu unterstützten SCM-Systemen, private Abhängigkeitsautorisierung, veröffentlichte Netzwerkbereiche und isolierte temporäre Build-Umgebungen. Daraus dürfen Sie keine allgemeine Zusage für beliebige VPNs, private Subnetze oder dedizierte Leitungen ableiten. Für einen Drittanbieter-Gateway, einen Reverse Proxy oder einen Dependency-Mirror benötigen Sie dessen eigene Dokumentation und einen Test in Ihrer Umgebung.

Ordnen Sie den Fall so zu:

Kontrolliert per HTTPS exponierbar: Xcode Cloud kann eine Option bleiben, wenn Authentifizierung, IP-Filter und Datenklassifizierung akzeptiert werden.
Nur lesbarer Mirror möglich: Spiegeln Sie die benötigten Pakete oder Artefakte in einen ausdrücklich für CI vorgesehenen Dienst. Prüfen Sie Aktualität, Signatur und Rücknahmeprozess.
Vorgebaute Artefakte zulässig: Bauen Sie die interne Komponente in einer kontrollierten Umgebung und übergeben Sie nur ein verifiziertes Ergebnis an die externe Testpipeline.
Keine externe Erreichbarkeit erlaubt: Routen Sie den Build auf einen Remote Mac innerhalb der kontrollierten Netzarchitektur.

Ein erfolgreicher curl- oder DNS-Befehl in einem benutzerdefinierten Skript ist dabei nur ein Testsignal. Er beantwortet nicht automatisch die Fragen nach Datenklassifizierung, Zertifikatsbindung, Dienstberechtigung oder Produktionsfreigabe.

Entscheidungsliste für die Hybrid-Pipeline

Nutzen Sie diese Liste als Abnahme- und Routingwerkzeug. Setzen Sie einen Punkt erst dann auf „erfüllt“, wenn ein Log, eine Berechtigungsprüfung oder ein Netzwerkprotokoll den Befund belegt.

[ ] Netzwerkpfad bestätigt: Der konkrete Hostname der Abhängigkeit wird aus der Build-Umgebung aufgelöst und über den genehmigten Weg erreicht.
Wenn erfüllt: Xcode Cloud bleibt für diesen Schritt zulässig.
Wenn nicht erfüllt: Mirror, kontrolliertes HTTPS oder Remote Mac prüfen.
[ ] Firewallquelle bestätigt: Die verwendeten Apple-Adressbereiche sind mit der aktuellen offiziellen Dokumentation abgeglichen und nicht nur aus einem alten Ticket übernommen.
Wenn erfüllt: Die Netzwerkfreigabe kann gezielt bewertet werden.
Wenn nicht erfüllt: Keine weitere Fehleranalyse als „Berechtigungsproblem“ etikettieren.
[ ] SCM-Autorisierung bestätigt: Die Organisation, das Repository und die konkrete CI-Verbindung besitzen die erforderlichen Leserechte.
Wenn erfüllt: Haupt-Repository und private SCM-Abhängigkeiten separat testen.
Wenn nicht erfüllt: SCM- oder IAM-Team muss die Verbindung korrigieren.
[ ] Paketauflösung bestätigt: Package.resolved, Paketversionen und verschachtelte private Abhängigkeiten funktionieren im PoC.
Wenn erfüllt: Der Swift-Package-Schritt kann in Xcode Cloud bleiben.
Wenn nicht erfüllt: Versions-, Netzwerk- und Authentifizierungsfehler getrennt behandeln.
[ ] Interner Dienst ohne Sondertunnel erreichbar: Der Artefaktserver benötigt weder eine nicht verfügbare VPN-Einwahl noch eine feste private Identität.
Wenn erfüllt: Kontrollierte HTTPS-Anbindung oder ein schreibgeschützter Mirror ist möglich.
Wenn nicht erfüllt: Betroffenen Schritt auf einen kontrollierten Remote Mac verlagern.
[ ] Temporäre Umgebung ausreichend: Der Build benötigt keinen dauerhaften Cache, keine Maschinenkonfiguration und keinen privilegierten Zugriff.
Wenn erfüllt: Benutzerdefinierte Skripte können die Vorbereitung reproduzierbar erledigen.
Wenn nicht erfüllt: Feste Abhängigkeiten und interne Zustände auf einen eigenen Knoten verschieben.
[ ] Signaturgrenze eingehalten: Sensible Produktionssignaturen sind von gewöhnlichen Pull-Request- und Testaufgaben getrennt.
Wenn erfüllt: Die Aufgaben können in einer Hybridpipeline gezielt geroutet werden.
Wenn nicht erfüllt: Signaturidentität und Zugriffsentzug neu entwerfen.
[ ] Rückfall nach Ausfall geprüft: Ein blockierter Dienst, ein Neustart und der Entzug eines Testzugangs führen zu einem kontrollierten Ergebnis.
Wenn erfüllt: Die Pipeline ist für einen erweiterten Pilotbetrieb geeignet.
Wenn nicht erfüllt: Keine dauerhafte Kapazität oder zusätzliche Projekte freischalten.

Die Entscheidung ist damit eindeutig: Sind alle relevanten Punkte für den externen Build erfüllt, kann Xcode Cloud den Workflow übernehmen. Scheitert ein Punkt an einer echten Intranet- oder Identitätsgrenze, gehört der betroffene Teil auf einen kontrollierten Remote Mac. Nicht jede Pipeline muss vollständig auf eine Plattform wechseln.

PoC-Ablauf für IT- und Sicherheitsteams

Führen Sie den Nachweis nicht mit dem produktiven Release-Projekt durch. Nutzen Sie ein isoliertes PoC-Repository und arbeiten Sie die folgenden Schritte ab:

Ressourcen inventarisieren: Erfassen Sie Haupt-Repository, private Swift Packages, Git-Submodule, Artefaktserver, Zertifikate, Signaturdienste und DNS-Namen.
Netzpfade dokumentieren: Notieren Sie für jede Ressource Zielhost, Protokoll, erwartete Quelle, TLS-Anforderung und VPN-Abhängigkeit.
Minimalprojekt anlegen: Verwenden Sie nur eine kleine App mit einer privaten Paketabhängigkeit und einem klaren Build-Skript.
SCM-Verbindung testen: Prüfen Sie Klonen, Branch-Zugriff und – falls relevant – Submodul-Auflösung mit der tatsächlichen CI-Autorisierung.
Swift-Package-Auflösung testen: Fixieren Sie die Version, erfassen Sie den Resolver-Fehler und unterscheiden Sie Netzwerk-, Berechtigungs- und Versionsprobleme.
Interne Artefakte separat prüfen: Laden Sie ein nicht sensibles Testartefakt und dokumentieren Sie DNS, TLS, Dienstkonto und Protokollereignis.
Fehlerpfade erzwingen: Entziehen Sie testweise eine Berechtigung oder blockieren Sie eine Route und prüfen Sie, ob der Build kontrolliert mit einer verständlichen Ursache abbricht.
Remote-Mac-Fallback validieren: Wiederholen Sie denselben Build auf einem kontrollierten Remote Mac und prüfen Sie, ob private Ressourcen, Signaturvoraussetzungen und der definierte Netzwerkpfad verfügbar sind.
Neustart und Entzug prüfen: Starten Sie den Knoten neu, widerrufen Sie einen Testzugang und bestätigen Sie, dass keine alte Sitzung oder geheime Datei den Zugriff fortsetzt.
Routing festschreiben: Legen Sie pro Job fest, ob er in Xcode Cloud, auf dem Remote Mac oder in einer zweistufigen Pipeline ausgeführt wird.

Bewerten Sie die PoC-Ergebnisse mit fünf Prüfpunkten: Quellcodeübergabe, Artefaktintegrität, minimale Berechtigungen, definierter Rückfall und Entzug von Personen- oder Dienstzugängen. Ein grüner Build allein reicht nicht als Abnahme.

Für die Planung eines kontrollierten Apple-Silicon-Knotens können Sie ergänzend die Informationen zu einem M4-Rechenknoten für Remote-Mac-Workloads heranziehen. Wenn Sie die Netzwerktrennung und den physischen Bereitstellungsansatz bewerten, ist auch der Vergleich Bare Metal gegenüber macOS-Virtualisierung relevant. Für interne Ressourcen zählt dabei nicht nur die Rechenleistung, sondern vor allem, ob der Knoten in Ihre Zugriffs-, Audit- und Wiederherstellungsprozesse passt.

Was gegen eine reine Xcode-Cloud-Lösung spricht

Xcode Cloud ist für den Teil Ihrer Pipeline sinnvoll, der mit unterstützten SCM-Verbindungen, freigegebenen Netzwerkwegen und temporären Umgebungen reproduzierbar funktioniert. Eine reine Lösung wird jedoch problematisch, wenn Sie mehrere interne Annahmen gleichzeitig benötigen: VPN-Zugriff, private DNS-Auflösung, Client-Zertifikate, dauerhafte Caches oder eine feste Signaturidentität.

Dann entstehen vier konkrete Nachteile:

Sie müssen interne Dienste möglicherweise weiter exponieren, als es Ihre Sicherheitsrichtlinie erlaubt.
Fehler werden schwerer zuzuordnen, weil SCM-Autorisierung und Netzwerkreichweite getrennt untersucht werden müssen.
Temporäre Umgebungen eignen sich nicht als Ersatz für einen dauerhaft konfigurierten internen Build-Knoten.
Ein Release kann an einer einzelnen privaten Abhängigkeit blockieren, obwohl der öffentliche Teil der Pipeline fehlerfrei läuft.

Ein selbst verwalteter Mac beseitigt diese Grenzen nicht automatisch. Sie tragen dann Patchmanagement, lokale Benutzer, Zugriffsentzug, Ersatzhardware und Monitoring selbst. Für einen zeitlich begrenzten PoC oder eine wachsende Pipeline kann ein kontrollierter Remote Mac dennoch die bessere Zwischenstufe sein: Sie behalten die notwendige Netzwerkidentität, ohne sofort jeden Entwicklerarbeitsplatz mit eigener Hardware auszustatten.

Wenn Sie genau eine private Abhängigkeitskette testen müssen, ist die sinnvollste nächste Aktion daher kein großflächiger Firewall-Umbau. Starten Sie mit einem isolierten PoC auf einem kontrollierten Remote Mac, prüfen Sie Repository-Zugriff, Swift-Package-Auflösung, internen Artefaktabruf, Neustart, Fehler-Rückfall und Berechtigungsentzug. Erst wenn diese Nachweise vorliegen, entscheiden Sie, ob Xcode Cloud allein genügt, ein dedizierter Knoten erforderlich ist oder eine dauerhafte Hybridpipeline den geringsten Betriebsaufwand verursacht. Für einen solchen zeitlich begrenzten Test oder zusätzliche CI-Kapazität können Sie die verfügbaren Remote-Mac-Optionen von MacDate prüfen.