CI/CD und Git: 5 Tipps für CI-freundliche Git-Repositorys

Ein externes Storage-System wie Artifactory (das über ein Add-on für Bamboo verfügt), Nexus oder Archiva kann für Artefakte, die von deinem Team oder den Teams um dich herum generiert wurden, hilfreich sein. Die benötigten Dateien können zu Beginn deines Builds in das Build-Verzeichnis gepullt werden – genauso wie die Bibliotheken von Drittanbietern, die du über Maven oder Gradle pullst.

Wenn in deinem Netzwerk noch kein externes Storage-System vorhanden ist, bietet sich Git Large File Storage (LFS) als unkomplizierteste Lösung an.

Git LSF ist eine Erweiterung, die Verweise auf große Dateien statt der Dateien an sich im Repository speichert. Die Dateien selbst werden auf einem Remote-Server gespeichert. Wie du dir vorstellen kannst, reduziert dies die zum Klonen benötigte Zeit erheblich.

Wahrscheinlich hast du bereits Zugriff auf Git LFS, da es von Bitbucket und GitHub unterstützt wird.

Angenommen, für deinen Build wird tatsächlich der vollständige Repository-Verlauf benötigt – beispielsweise, weil mit einem der Schritte in deinem Build die Versionsnummer im POM (o. ä.) aktualisiert wird oder weil du mit jedem Build zwei Branches mergst. In beiden Fällen muss Bamboo Änderungen an dein Repository zurück übermitteln.

Mit Git können einfache Änderungen an Dateien (zum Beispiel die Aktualisierung einer Versionsnummer) ohne den gesamten Verlauf gepusht werden. Für einen Merge ist jedoch weiterhin der komplette Verlauf des Repositorys erforderlich, da Git zurückblicken muss, um den gemeinsamen Vorfahren der beiden Branches zu finden – dies wird zum Problem, wenn dein Build oberflächliche Klone nutzt. Und hiermit kommen wir zu Tipp Nr. 3.

Dadurch wird auch der Klonvorgang erheblich beschleunigt, weshalb dies bei Bamboo Standard ist.

Ein Hinweis: Repository-Caching ist nur von Vorteil, wenn deine Agenten von Build zu Build erhalten bleiben. Wenn du Agenten auf EC2 oder bei einem anderen Cloud-Anbieter bei jedem Build neu erstellst und später wieder entfernst, hat das Repository-Caching keinen Nutzen, weil du dann mit einem leeren Build-Verzeichnis arbeitest und ohnehin jedes Mal eine vollständige Kopie des Repositorys abrufen musst.

Flache Klone plus Repository-Caching, geteilt durch bleibende Agenten gegenüber elastischen Agenten ergibt ein spannendes Netz aus Faktoren. Hier eine kleine Matrix, die dir beim Entwickeln einer Strategie hilft.

Es ist (nahezu) selbstredend, dass die Ausführung von CI in allen aktiven Branches eine gute Idee ist. Aber ist es sinnvoll, bei jedem Commit die Builds für alle Branches laufen zu lassen? Eher nicht. Und zwar aus folgendem Grund.

Nehmen wir zum Beispiel Atlassian. Bei uns arbeiten über 800 Entwickler, die alle mehrmals täglich ihre Änderungen in das Repository pushen – meistens in ihre Feature-Branches. Das sind eine Menge Builds. Wenn die Zahl an Build-Agenten nicht umgehend ins Unermessliche erhöht wird, sind lange Wartezeiten vorprogrammiert.

Einer unserer internen Bamboo-Server beherbergt 935 verschiedene Build-Pläne. Wir hatten 141 Build-Agenten an diesen Server angeschlossen und nutzten Best Practices wie das Weiterleiten von Artefakten und Paralleltests, um jeden Build so effizient wie möglich zu gestalten. Trotzdem führten die Builds nach jedem Push zu Engpässen.

Anstatt einfach eine weitere Bamboo-Instanz mit mindestens 100 zusätzlichen Agenten einzurichten, sind wir in uns gegangen und haben uns gefragt, ob dies wirklich nötig ist. Die Antwort darauf lautete schließlich: Nein, ist es nicht.

Also haben wir Entwicklern die Möglichkeit gegeben, ihre Branch-Builds selbst zu kontrollieren, statt sie immer automatisch triggern zu lassen. Dies ist ein guter Weg, um ein ausgewogenes Verhältnis zwischen strikten Tests und Ressourcenschonung zu erzielen. Da die meisten Änderungsaktivitäten in Branches stattfinden, ist das Einsparpotenzial dort am größten.

Viele Entwickler wissen die stärkere Kontrolle bei nicht-automatischen Builds zu schätzen und finden, dass sich diese Builds gut in ihren Workflow einfügen. Andere Entwickler möchten lieber nicht selbst über den optimalen Zeitpunkt zum Erstellen eines Builds entscheiden und behalten die automatischen Trigger bei. Beide Ansätze können funktionieren. Wichtig ist nur, die Branches zunächst zu testen und so sicherzustellen, dass dein Build sauber ist, bevor du ihn upstream mergst.

Wichtige Branches wie der Haupt-Branch und stabile Release-Branches sind allerdings ein ganz anderes Thema. Dort werden Builds automatisch ausgelöst – entweder durch das Abrufen von Änderungen aus dem Repository oder durch das Senden einer Push-Benachrichtigung von Bitbucket an Bamboo. Da wir Entwicklungs-Branches für alle laufenden Arbeiten nutzen, sollten (theoretisch) auch nur Entwicklungs-Branches und keine anderen Commits in den Haupt-Branch gemergt werden. Dies sind außerdem die Codezeilen, auf denen unsere Releases und Entwicklungs-Branches basieren. Es ist daher sehr wichtig, frühzeitig Testergebnisse zu jedem Merge zu erhalten.

Für Bamboo ist es kein Problem, das Repository alle paar Minuten auf Änderungen abzufragen. Wenn jedoch mehrere Hundert Builds und mehrere Tausend Branches mit Dutzenden Repositorys vorhanden sind, summieren sich die Prozesse schnell. Statt Bamboo mit all diesen Abfragen zu belasten, kannst du Bitbucket so einrichten, dass signalisiert wird, wenn eine Änderung gepusht wurde und ein Build erforderlich ist.

In der Regel musst du dein Repository dafür mit einem Hook versehen, doch die Integration von Bitbucket und Bamboo nimmt dir praktischerweise die gesamte Einrichtung ab. Sobald Bamboo und Bitbucket Server am Back-End verbunden sind, lassen sich Repository-orientierte Builds ohne weiteres Eingreifen auslösen. Es sind keine Hooks oder spezielle Konfigurationen erforderlich.

Unabhängig von den Tools haben Repository-orientierte Trigger den Vorteil, dass sie automatisch wieder verschwinden, sobald der Ziel-Branch nicht mehr aktiv ist. Anders gesagt wirst du so nie die CPU-Zyklen deines CI-Systems mit der Abfrage Hunderter stillgelegter Branches vergeuden. Oder deine eigene Zeit beim manuellen Stilllegen von Branch-Builds. (Es sei jedoch angemerkt, dass in Bamboo das Ignorieren von Branches nach einer bestimmten Anzahl von Tagen problemlos konfiguriert werden kann, falls du weiterhin Abfragen bevorzugst.)