Thema: ci-cd
-
Ab welcher Repository-Grösse brauchen Teams Monorepo-Build-Werkzeuge über blosses Git hinaus?
Offene Frage: Sparse Checkout, Partial Clone und Per-Verzeichnis-CI-Filter decken die erste Phase eines wachsenden Einzelrepositorys ab; bei welcher Grösse, Teamzahl oder Build-Zeit haben Teams festgestellt, dass ein Build-Graph-Werkzeug mit Remote-Caching nötig wurde, und was kostete der Übergang?
-
Einen Build durch die Umgebungen befördern: Konfigurationsübernahme und Dev-Prod-Parität
Ein Artefakt einmal bauen, ihm eine unveränderliche Identität geben und genau dieses Artefakt von Test über Staging bis Produktion befördern, wobei sich nur die umgebungsspezifische Konfiguration ändert; Umgebungen bei Backing Services und Topologie angleichen, damit eine bestandene Stufe die nächste zuverlässig vorhersagt.
-
GitHub-Actions-Workflows absichern: Actions per SHA anheften, Tokens nach dem Prinzip der geringsten Rechte, nicht vertrauenswürdige Eingaben
Actions von Drittanbietern auf den vollständigen Commit-SHA anheften, das GITHUB_TOKEN standardmässig auf Nur-Lese setzen und pro Job gezielt erweitern, nicht vertrauenswürdige Event-Felder nie in run-Skripte einsetzen, und pull_request_target sowie workflow_run als privilegierte Trigger behandeln.
-
Build-Caching in CI: Schlüssel, Restore-Fallbacks und Cache-Vergiftung
Ein CI-Cache wird über einen Hash der Lockfile-Datei geschlüsselt, mit geordneten Fallback-Schlüsseln, ist auf Branches begrenzt, wobei der Default-Branch als gemeinsamer Elternteil dient, und wird nach Grösse oder Alter geräumt; Docker-Layer-Caches müssen in CI ausdrücklich exportiert und importiert werden. Caches sind nicht signiert, daher kann alles, was in einen vertrauenswürdigen Scope schreiben kann, Code in spätere Builds einschleusen.
Maschinenlesbar: JSON