2026 Kleine Teams: Geteilter Remote-Mac — Build-Warteschlange FAQ: Seriengrenze, flock-Dateisperren und Parameter zur Konfliktvermeidung

FAQ: Wann ist strikte Serialisierung besser als begrenzte Parallelität?

Strikte Serialisierung bedeutet: höchstens ein „schwerer“ Build-Pipeline-Lauf berührt gemeinsamen, veränderlichen Zustand zur selben Zeit — ein Archiv-Lauf, eine Simulator-lastige Integrationstest-Welle oder ein Job, der in einen gemeinsamen Abhängigkeits-Cache schreibt. Das ist unsubtil: unter Last steigt die Latenz, aber Sie vermeiden subtile Korruption und nicht reproduzierbare Artefakte.

Begrenzte Parallelität (etwa zwei gleichzeitige leichte Jobs) funktioniert nur, wenn jeder Job isolierte Arbeitsverzeichnisse, nicht überlappende Ausgabepfade und getrennte Budgets für RAM und I/O hat. Teilen sich zwei Jobs weiterhin ein CocoaPods-Verzeichnis, einen globalen npm-Cache ohne Namespace oder ein Xcode-Projekt, das interaktiv über VNC geöffnet ist, während CI kompiliert, werden aus Geschwindigkeitsgewinnen schnell Vorfälle.

Faustregel: seriell starten, sobald schwere Jobs und gemeinsame Caches zusammentreffen; zu begrenzter Parallelität erst wechseln, wenn Metrik und Isolation das tragen (CPU dauerhaft unter etwa 75 %, freier RAM nach macOS grob 8–16 GB) und pro Job klar abgegrenzte Workspaces existieren. Ergänzend hilft der Überblick über Pool-Grenzen in der FAQ zum geteilten Remote-Mac-Pool (Warteschlange, Quota, Konflikte).

FAQ: Wie setzen wir flock auf dem gemeinsamen Builder ein?

flock koordiniert beratende (advisory) Dateisperren: kooperative Prozesse halten sich daran; böswillige oder fehlerhaft konfigurierte Jobs ersetzen keine Sandbox. Auf einem geteilten Mac verwenden Sie eine Sperrdatei pro gemeinsamer Ressourcendomäne — etwa /var/lib/build-locks/pod-shared.lock für einen gemeinsamen Pod-Cache oder /var/lib/build-locks/simulator-ui.lock, wenn nur ein GUI-Simulator-Strom laufen darf.

• Schnell scheitern: flock -n /pfad/zur.lock -- kritisch_befehl — bricht sofort ab, wenn die Sperre belegt ist; sinnvoll, wenn Ihr CI den Job auf einem anderen Knoten wiederholen soll.
• Warten mit Deckel: flock -w 180 /pfad/zur.lock -- kritisch_befehl — wartet bis zu 180 Sekunden; passend für kurze kritische Abschnitte wie Cache-Schreiben nach Dependency-Auflösung.
• Kritische Abschnitte klein halten: nur mutierende Schritte (Install, Cache-Write, Index-Refresh) unter Sperre, nicht die gesamte 40-Minuten-Kompilation — außer das Tooling erzwingt es wirklich.

Shell-flock sollte zur Artefakt-Politik passen: wer parallel promotet, braucht zusätzlich Staging und atomare Veröffentlichung auf Dateisystemebene — sonst ersetzt die Sperre nur einen Teil der Race-Conditions.

FAQ: Warteschlangentiefe, Job-Timeouts und Sperrwarte-Timeouts

Eine Obergrenze für die Warteschlangentiefe verhindert stilles Verhungern. Wenn fünfzig Pipelines ohne Limit einreihen können, wirkt der Mac „kaputt“, obwohl er nur gesättigt ist. Pragmatischer Startwert: global oder pro Spur (Release vs. PR) etwa 20 ausstehende Jobs — danach scheitern neue Läufe mit klarer Meldung („Pool gesättigt — später erneut versuchen oder anderes Label“).

Job-Timeouts sollten der längsten sinnvollen Build-Zeit entsprechen, nicht dem längsten Hackathon-Lauf. Orientierungswerte: Lint und kleine Unit-Suites 15–25 Minuten; voller Compile- und Testzyklus 35–60 Minuten; App-Store-nahes Archiv inkl. Upload 45–90 Minuten. Kalibrieren Sie anhand der p95-Laufzeiten plus Puffer und verkürzen Sie aggressiv, wenn Jobs Ressourcen lecken.

Sperrwarte-Timeouts (flock -w) sollten kürzer sein als Job-Timeouts: wenn eine gemeinsame Cache-Sperre über Minuten nicht zu erhalten ist, steckt vermutlich ein anderer Job fest oder der kritische Abschnitt ist zu groß — das ist ein Alarm-Signal, kein Übernacht-Warten.

FAQ: Knotenstabilität, hängende Sperren und Konfliktbehandlung

Stabilität auf einem geteilten Mac heißt: beobachtbare Warteschlangen plus begrenzte Nebenwirkungen. Messen Sie mediane Wartezeit, p95 der Sperrwartezeit, freien Speicher auf dem Systemvolume und Swap-Aktivität. Alarmieren Sie, wenn die mediane Wartezeit an einem Werktag dauerhaft über etwa 15 Minuten steigt oder weniger als etwa 15 % freier Speicher oder 40 GB (je nachdem, was größer ist) übrig bleiben.

Konflikte — doppelte Klone, Simulator-Boot-Rennen, Signing-Dialoge — sind Entwurfsschulden. Kurzfristig: hängenden Job abbrechen, prüfen ob noch ein Prozess die Sperrdatei hält, Runner-ID dokumentieren, nur den Worker-Dienst neu starten, wenn der Orchestrator-Zustand klemmt. Langfristig: interaktive und CI-Pools trennen, UI-Tests auf einen eigenen Knoten legen oder vor höherer Parallelität einen zweiten Builder hinzufügen.

SSH-Keepalives, Reconnect-Erwartungen und interne SLAs sollten mit Ihrer Stabilitätsdokumentation übereinstimmen, damit Transport-Flakes nicht fälschlich als Sperrkontention interpretiert werden.

Parameterblatt für Runbooks (kopierbar)

Ops-Checkliste: Warteschlangen, Sperren, Konflikte

1. Sperrdateien nach Ressource benennen, nicht nach Team — eine Sperre pro gemeinsamer Pod-/npm-/Simulator-Domäne.
2. Warteschlangen-Obergrenzen intern dokumentieren und in CI-Fehlertexten ausgeben; bei Überlauf Retry-Hinweis liefern.
3. flock-Wartezeiten kürzer als Job-Timeouts halten; wiederholte Sperr-Timeouts alarmieren.
4. Vor dem Löschen von Lock-Dateien hängende Jobs verifizieren; Runner-ID, Commit und Sperrpfad für Audits loggen.
5. Wöchentlich prüfen: Trend Warteschlangentiefe, freier Speicher, DerivedData-Wachstum, ob serielle Spuren gesplittet werden müssen.