Die wichtigste Kennzahl ist nicht die gesamte Laufzeit des Jobs. Sie brauchen eine Phasenmessung für:

• normalen Git-Transport und Referenzauflösung,
• Download der Git-LFS-Objekte,
• Befüllung des Arbeitsbereichs,
• Wiederherstellung von Abhängigkeiten,
• eigentlichen Xcode-Build,
• Wartezeit vor dem Start und nach einem Fehler.

Ein kompletter Checkout kann erfolgreich sein, obwohl im Arbeitsbereich noch nur Pointer-Dateien liegen. Git LFS trennt diese Pointer von den eigentlichen Objekten. Die offiziellen Git-LFS-Erklärungen beschreiben, wie die kleinen Pointer im Git-Repository liegen, während die großen Dateien separat gespeichert und abgerufen werden (offizielle Git-LFS-Mechanik).

Kaltstart und Wiederholung

Legen Sie für denselben Commit zwei Baselines an:

1. einen Kaltstart ohne nutzbaren lokalen LFS-Objektbestand,
2. eine Wiederholung mit einem kontrollierten, vorher bekannten Cache.

Erfassen Sie bei jedem Lauf mindestens:

• Start- und Endzeit des normalen Git-Abrufs,
• übertragene LFS-Bytes,
• Anzahl und Größe der angeforderten Objekte,
• Zeit bis zur vollständigen Workspace-Befüllung,
• Zeit für Dependency Restore,
• Xcode-Buildzeit,
• Queue-Zeit vor der Ausführung,
• Fehler und Wiederholungen.

Diese Messung beantwortet die erste Beschaffungsfrage: Wartet der Job auf Daten oder rechnet der Mac? Wenn Netzwerk- und LFS-Wartezeit den größten Anteil bilden, bringt ein leistungsfähigerer Mac zunächst wenig. Wenn Xcode nach abgeschlossenem Checkout dauerhaft unter hoher CPU- oder Speicherauslastung läuft, wird eine Kapazitätserweiterung plausibel.

Die Begriffe müssen dabei strikt getrennt bleiben: Git-Objekt, LFS-Pointer, LFS-Objekt, Workspace-Datei, Dependency-Cache und Xcode-Build-Cache sind keine austauschbaren Speicherarten. Eine gemeinsame „Checkout-Zeit“ verschleiert genau die Grenze, an der Ihre Investition wirken soll.

Git LFS wird oft als ein einzelner Downloadschritt behandelt. Das führt zu falschen Entscheidungen. Ein erfolgreicher fetch bedeutet nicht automatisch, dass jede benötigte Datei im Arbeitsbereich ausgecheckt wurde. Die offizielle Beschreibung von git lfs fetch erklärt, dass Objekte in den lokalen LFS-Speicher geladen werden können, ohne den Arbeitsbereich vollständig zu aktualisieren (Git-LFS-Fetch-Handbuch).

Warum wächst die Checkout-Zeit?

Die Ursache kann in mehreren Schichten liegen:

• Ein Pull-Request-Job lädt Objekte aus nicht relevanten Verzeichnissen.
• Die Pipeline verwendet eine zu breite Branch- oder Historienauswahl.
• Ein flacher Clone reduziert zwar die Git-Historie, löst aber nicht automatisch die LFS-Auswahl.
• Mehrere Jobs laden dieselben großen Objekte erneut.
• Der Workspace wird nach dem Objektabruf unnötig vollständig neu aufgebaut.
• Der LFS-Endpunkt hat eine andere Latenz oder Bandbreite als der Mac-Knoten.

Prüfen Sie deshalb die tatsächliche Objektliste des Repositorys. Vergleichen Sie sie mit den Pfaden, die der konkrete Job benötigt. Die Zahl im Repository-Inventar und die übertragenen Bytes sind belastbare Belege; eine allgemeine Annahme über die Repository-Größe ist es nicht.

Selektive Pfade

Für Pull-Request-Prüfungen kann eine Pfadstrategie sinnvoll sein, wenn die Aufgabe nur einen klar abgegrenzten Ressourcenbestand benötigt. Git LFS unterstützt dafür Include- und Exclude-Muster. Die genaue Wirkung sollten Sie mit der zum Zeitpunkt Ihrer Ausführung installierten Git-LFS-Version in einem isolierten Repository prüfen, statt das Verhalten eines Checkout-Plugins zu unterstellen.

Ein minimales Diagnosemuster kann so aussehen:

git lfs fetch --include="Assets/Module-A/**"
git lfs checkout

Das ist keine vollständige Pipeline-Konfiguration. Es zeigt nur die Reihenfolge: Objektbestand gezielt abrufen, danach Dateien im Arbeitsbereich materialisieren. Für andere Jobs kann ein Ausschlussmuster sinnvoller sein:

git lfs fetch --exclude="Assets/Archive/**"

Die offiziellen Git-LFS-Handbücher sind für die zulässigen Muster und deren aktuelle Semantik maßgeblich (Git-LFS-Fetch-Referenz).

Branch- und Tiefenprüfung

Kontrollieren Sie im Checkout:

• Welche Branches werden tatsächlich benötigt?
• Wird die Historie für den Job vollständig oder begrenzt geladen?
• Werden Tags oder zusätzliche Referenzen ohne Nutzen abgerufen?
• Enthält der Job Ressourcen aus einem anderen Produktbereich?
• Wird ein gemeinsames Repository für unterschiedliche Testklassen verwendet?

Eine kleinere Clone-Tiefe kann den Git-Anteil reduzieren. Sie ist aber kein Ersatz für eine LFS-Pfadstrategie. Wenn der Job weiterhin dieselben LFS-Objekte abruft, verschiebt sich der Engpass nicht automatisch.

Ein dauerhaft verfügbarer Mac kann Git-LFS-Objekte wiederverwenden. Das ist ein Vorteil, aber kein Beweis für einen wirksamen Cache. Sie müssen die Wiederverwendung beobachten. Ein gefülltes Verzeichnis kann veraltet, unvollständig, falsch zugeordnet oder durch einen fehlerhaften Workspace unbrauchbar sein.

Für die Beurteilung protokollieren Sie:

• übertragene Bytes je Lauf,
• Anteil bereits vorhandener Objekte,
• Zeit bis zum verfügbaren Workspace,
• Wachstum des lokalen Speichers,
• Bereinigungsereignisse,
• Fehler nach Cache-Wiederverwendung.

Eine belastbare Aussage lautet dann etwa: „Der zweite Lauf benötigt weniger LFS-Transfer und erreicht den vollständigen Workspace früher.“ Die Aussage „Der Mac hat einen Cache und ist deshalb schneller“ reicht nicht.

Drei Betriebsmodelle

Einmalige Umgebung:
Ein kurzlebiger Knoten erhält Repository und Abhängigkeiten für einen Lauf. Das reduziert die Lebensdauer sensibler Daten, wiederholt aber den Kaltstart. Dieses Modell passt zu nicht vertrauenswürdigen Branches oder stark wechselnden Aufgaben.

Dauerhaft zugewiesener Mac:
Ein fester Knoten kann LFS-Objekte und Abhängigkeiten kontrolliert wiederverwenden. Dafür benötigen Sie klare Eigentümer, Speichergrenzen, Bereinigung und eine Wiederherstellungsroutine. Ein einzelner Arbeitsbereich darf nicht als globaler Cache für mehrere Projekte behandelt werden.

Geteilter Workspace:
Er kann die Übertragung reduzieren, erhöht aber die Gefahr von Restdateien, falschen Build-Artefakten und Cross-Project-Leaks. Für reproduzierbare Releases ist diese Variante nur vertretbar, wenn der Workspace vor und nach jedem Job verifiziert oder vollständig neu aufgebaut wird.

Achtung: Ein LFS-Objekt-Cache ist nicht dasselbe wie ein vertrauenswürdiger Arbeitsbereich. Wiederverwendung darf die Herkunft und Integrität der Dateien nicht verschleiern. Prüfen Sie deshalb den erzeugten Workspace mit einem reproduzierbaren Test, bevor Sie ein signiertes Artefakt akzeptieren.

Für selbstverwaltete Mac-Runner sollten Sie Cache-Verzeichnisse nach Projekt, Vertrauensstufe und gegebenenfalls Release-Kanal trennen. Ein Pull Request aus einem nicht vertrauenswürdigen Kontext darf keinen langfristigen Produktions-Token erben. Die Dokumentation zum sicheren Einsatz von selbstverwalteten Runnern beschreibt das grundsätzliche Risiko solcher Ausführungsumgebungen (Sicherheit selbstverwalteter Runner).

Die Beschleunigung darf nicht auf Kosten der Wiederholbarkeit gehen. Prüfen Sie für jeden Job, ob der Build reale Dateien oder nur LFS-Pointer sieht. Ein einfacher Test kann die erwartete Ressource öffnen, ihre Größe prüfen und einen Hash gegen eine bekannte Referenz vergleichen. Die konkreten Werte müssen aus Ihrem Repository und Ihrer Builddefinition stammen.

Trennen Sie mindestens diese Berechtigungen:

• Lesen von Git-Referenzen,
• Lesen von Git-LFS-Objekten,
• Schreiben von Cache-Inhalten,
• Zugriff auf Signaturmaterial,
• Veröffentlichung eines Release-Artefakts.

Ein Token für den LFS-Download sollte nicht automatisch die Rechte eines Produktionssignierers besitzen. Ebenso sollte ein Cache-Schreibrecht nicht den Zugriff auf fremde Projektpfade ermöglichen.

Die Checkout-Komponente kann Optionen für LFS, Sparse Checkout und Credentials unterschiedlich umsetzen. Prüfen Sie daher die Dokumentation und die Versionsangabe der konkret eingesetzten Komponente (Dokumentation der Checkout-Komponente). Verlassen Sie sich nicht auf den Namen einer Option allein.

Akzeptanztests für die Integrität

Führen Sie nach jeder Änderung mindestens diese Kontrollen aus:

1. Der Commit entspricht der erwarteten Referenz.
2. Alle für die Aufgabe benötigten LFS-Dateien sind materialisiert.
3. Keine Pointer-Datei wird irrtümlich an Xcode übergeben.
4. Der Build kann den benötigten Ressourcensatz öffnen.
5. Ein identischer Lauf erzeugt ein vergleichbares Ergebnis.
6. Der Workspace enthält keine Datei aus einem fremden Projekt.
7. Produktions-Credentials sind im Log und im Arbeitsverzeichnis nicht sichtbar.

Die Liste ist kein Ersatz für eine Sicherheitsprüfung. Sie verhindert aber, dass eine kürzere Checkout-Zeit mit einem unvollständigen oder kontaminierten Build erkauft wird.

Nach der Checkout-Optimierung verschiebt sich der Engpass möglicherweise. Erst dann lohnt die Kapazitätsrechnung. Verwenden Sie dafür keine Entwickleranzahl und keine allgemeine Produktwerbung, sondern reale Pipeline-Daten:

• effektive Buildzeit nach abgeschlossenem Checkout,
• Ankunftsrate der Jobs,
• maximale und typische Queue-Zeit,
• gleichzeitige Ausführung,
• Fehler- und Wiederanlaufquote,
• benötigte Redundanz bei einem Knotenausfall.

Mehr Netzwerkdurchsatz hilft, wenn die LFS-Übertragung wartet. Ein zusätzlicher Cache-Knoten hilft, wenn Objekte wiederholt aus einem entfernten Speicher geholt werden. Ein weiterer echter Mac-Build-Knoten hilft erst, wenn die Warteschlange oder die verfügbare Rechenzeit der Engpass ist.

Stufenweise Umsetzung

1. Messpunkt definieren: Markieren Sie im CI-Log den Beginn und das Ende jeder Phase.
2. Repository-Inventar erstellen: Erfassen Sie LFS-Pfade, Objektgrößen, Branch-Auswahl und relevante Jobtypen.
3. Abruf reduzieren: Testen Sie Tiefenbegrenzung, Pfadfilter und getrennte Ressourcensätze in einer isolierten Pipeline.
4. Cache kontrollieren: Messen Sie kalte und wiederholte Läufe getrennt. Dokumentieren Sie Bytes, Zeit und Speicherwachstum.
5. Workspace isolieren: Trennen Sie Projekte und Vertrauensstufen. Löschen oder verifizieren Sie Arbeitsbereiche nach dem Job.
6. Credentials begrenzen: Verwenden Sie getrennte Tokens für Abruf, Cache und Signierung.
7. Realistische Last ausführen: Nutzen Sie eine echte iOS-Pipeline mit repräsentativen LFS-Ressourcen, nicht nur einen kleinen Test-Commit.
8. Kapazität prüfen: Vergleichen Sie Buildzeit, Queue-Zeit und Fehlerverhalten vor und nach der Änderung.
9. Betriebsmodell wählen: Entscheiden Sie zwischen festem Mac-Pool, elastischem Remote-Mac-Pool oder einer Kombination.
10. Rückfall definieren: Legen Sie fest, wann Jobs bei Cachefehlern, Knotenverlust oder fehlender Credential-Isolierung auf einen sicheren Pfad wechseln.

Ein fester Pool passt zu stabiler Grundlast, vertrauenswürdigen Projekten und planbaren Releasefenstern. Ein elastischer Remote-Mac-Pool passt zu Spitzen, temporären Branches und Kapazitätstests. Ein Mischmodell verbindet einen kleinen, dauerhaft kontrollierten Pool mit zusätzlichen Knoten für nachweisbare Lastspitzen.

Ihre TCO-Rechnung sollte zunächst nur überprüfbare Variablen enthalten:

TCO = Netzwerkverkehr + Speicherkosten + belegte Mac-Zeit + Betriebsaufwand + Fehlerauswirkungen

Die Variablen müssen aus Ihren Rechnungen, CI-Protokollen und Arbeitszeitaufzeichnungen stammen. Tragen Sie keine angenommenen Preise, Knotenwerte oder Einsparprozente ein, solange sie nicht aus einem konkreten Angebot, einer Rechnung oder einem eigenen Test stammen.

Die Abnahme sollte mindestens diese Fälle enthalten:

• Kaltstart ohne LFS-Objektbestand,
• Wiederholung mit kontrolliertem Cache,
• vollständige Ressource im Workspace,
• getrennte Credentials,
• Speicherbereinigung,
• Queue unter realer Last,
• Wiederanlauf nach Knotenverlust.

Bewerten Sie jeden Fall mit „bestanden“, „nicht bestanden“ oder „nicht ausreichend belegt“. Hinterlegen Sie die Logdatei, die Objektliste, den Workspace-Nachweis und die Entscheidung. Daraus entstehen drei klare Ergebnisse: nur Git LFS optimieren, Mac-Kapazität erweitern oder einen festen vertrauenswürdigen Pool mit elastischen Remote-Macs kombinieren.

Entscheidungsmatrix

Wenn Sie Mac-Hardware zunächst selbst beschaffen wollen, sollte die Auswahl ebenfalls auf Ihrem Lastprofil beruhen. Für eine separate Geräteentscheidung können Sie etwa die Übersicht zu Mac-mini-Beschaffung als nächsten Recherchepunkt nutzen. Das ersetzt jedoch nicht den LFS-Test: Ein leistungsfähigeres Gerät korrigiert keine unnötig übertragenen Objekte.

Ein bestehender lokaler Mac-Pool hat gegenüber einer elastischen Umgebung klare Vorteile: Er behält kontrollierte Caches, bietet vorhersehbare Zugriffswege und kann für Signaturprozesse dauerhaft isoliert werden. Die Nachteile sind gebundenes Kapital, Wartung, Ersatzhardware und ungenutzte Kapazität außerhalb der Spitzen. Wenn Sie eine Beschaffung vergleichen, berücksichtigen Sie deshalb nicht nur den Gerätepreis, sondern auch Strom, Austausch, Administration, Standort, Ausfallzeit und die Zeit bis zur betriebsbereiten Konfiguration.

Wenn Ihre aktuelle Lösung dagegen nur wenige gemeinsam genutzte Macs vorsieht, entstehen oft drei reale Schwächen: Jobs warten auf dieselbe knappe Ressource, Caches und Arbeitsbereiche vermischen sich, und kurzfristige Lastspitzen führen zu manuellen Eingriffen. Einen Überblick über die verfügbaren Remote-Mac-Lösungen von KVMNODE können Sie für einen zeitlich begrenzten Vergleich heranziehen. Eine elastische Mac-Kapazität von KVMNODE kann dann als Pilot dienen. Verwenden Sie dafür dasselbe Repository, dieselben LFS-Pfade und dieselbe iOS-Pipeline. Vergleichen Sie Kaltstart, Cache-Wiederverwendung, echte Buildzeit, Queue und Wiederherstellung, bevor Sie feste Knoten ersetzen oder zusätzliche Kapazität dauerhaft einplanen.

Für Teams mit temporärem Bedarf, PoC-Phasen oder saisonalen Release-Spitzen ist dieser Vergleich aussagekräftiger als eine pauschale Aussage über „schnellere Macs“. Für dauerhaft hohe, vorhersehbare Last und Anforderungen an physische Schnittstellen oder lokale Spezialhardware kann der Kauf eigener Mac-Systeme weiterhin die bessere Entscheidung sein. Entscheidend ist, dass Ihre Beschaffung dem gemessenen Engpass folgt: erst Datenpfad und Cache, danach Mac-Rechenkapazität.