CI-freundliche Git-Repos¶
Im Folgenden möchte ich einige Tipps geben, wie Git-Repositories und Kontinuierliche Integration mit GitLab CI/CD oder GitHub Actions gut zusammenspielen können.
Speichert große Dateien außerhalb eures Repositories¶
Jedes Mal, wenn ein neuer Build erstellt wird, muss das Arbeitsverzeichnis geklont werden. Wenn euer Repository jedoch mit großen Artefakten aufgebläht ist, verlangsamt sich dieser und ihr müsst länger auf die Ergebnisse warten.
Wenn euer Build jedoch von Binaries aus anderen Projekten oder großen Artefakten abhängt, kann ein externes Speichersystem sinnvoll sein, das diejenigen Dateien, die ihr zu Beginn eures Builds im Build-Verzeichnis benötigt, zum Download bereitstellt.
Verwendet Shallow-Clones¶
Jedes Mal, wenn ein Build ausgeführt wird, klont euer Build-Server euer Projektarchiv in das aktuelle Arbeitsverzeichnis. Dabei klont Git üblicherweise die gesamte Historie des Repos, wodurch dieser Vorgang mit der Zeit immer länger dauert. Es sei denn, ihr verwendet sog. Shallow-Clones, bei denen mit git clone --depth nur der aktuelle Snapshot des Repos und mit git clone --branch nur der relevante Zweig heruntergezogen wird. Das verkürzt die Build-Zeit vor allem bei Repositories mit einer langen Geschichte und vielen Zweigen.
Dabei kann Git seit Version 1.9 einfache Änderungen an Dateien, wie z.B. das Aktualisieren einer Versionsnummer, vornehmen, ohne dass die gesamte Historie gepusht wurde.
Warnung
In einem shallow clone kann git fetch
dazu führen, dass ein fast
vollständiger Commit-Verlauf heruntergeladen wird. Auch andere
Git-Operationen können zu unerwarteten Ergebnissen führen und die
vermeintlichen Vorteile von Shallow-Clones zunichte machen, sodass wir
empfehlen, Shallow-Clones nur für Builds zu verwenden und das Repository
sofort danach wieder zu löschen.
Wollt ihr die Repositories jedoch weiterverwenden, kann der folgende Tipp hilfreich sein.
Cache des Repos auf Build-Servern¶
Dies beschleunigt auch das Klonen, da die Repos nur aktualisiert werden müssen.
Bemerkung
Der Cache von Repos ist nur dann von Vorteil, wenn die Build-Umgebung von Build zu Build bestehen bleibt. Wenn euer Build-Agent, z.B. Amazon EC2, den Build wieder abbaut, könnt ihr mit Caching jedoch nichts gewinnen.
Wählt die Trigger mit Bedacht¶
Es versteht sich fast von selbst, dass es eine gute Idee ist, CI auf all euren aktiven Zweigen laufen zu lassen. Aber es ist meist keine gute Idee, alle Builds auf allen Zweigen gegen alle Commits laufen zu lassen.
Üblicherweise geben wir allen im Entwicklungsteam die Möglichkeit, ihre
Zweig-Builds auf Knopfdruck zu erstellen, anstatt sie automatisch auszulösen.
Dies scheint uns ein guter Weg, um ein Gleichgewicht zwischen regelmäßigen Tests
und der Einsparung von Ressourcen zu schaffen. In kritischen Zweigen wie
main
oder stable
werden Builds jedoch automatisch ausgelöst. Zudem
erhalten wir automatisiert auch bei jedem Merge- oder Pull-Request zeitnahe
Testergebnisse.