Wer Git bereits eine Weile im Einsatz hat, dem sind Git Hooks vermutlich ein Begriff.

Vielleicht haben Sie sogar schon ein wenig damit herumgespielt. Im Kontext von Continuous Integration sind Git Hooks ein wunderbares Werkzeug. Im Rahmen dieses Artikels betrachten wir einige der Use Cases rund um Continuous Integration mit Git Hooks in Atlassian-Werkzeugen und verweisen auf einige Skript-Vorlagen des australischen Herstellers, die sich in der Praxis direkt einsetzen lassen.

Git Hooks verstehen

Hooks sind der in Git eingebaute Mechanismus, um beliebige Skripts vor oder nach Operationen wie Commits oder Merges auszulösen. Damit stellen Hooks eine Art Plugin für Git dar. Im .git-Verzeichnis eines jeden Repositories findet sich ein Ordner namens hooks, welcher bereits einige Beispiel-Skripte enthält.

Git Hooks zu installieren, ist einfach und gut dokumentiert. Aus diesem Grund gehen wir darauf im Rahmen des Artikels nicht weiter ein.

Es gibt zwei Varianten von Hooks: serverseitige und clientseitige. Clientseitige Hooks laufen auf dem lokalen Rechner, während serverseitige Hooks auf dem Git-Server ausgeführt werden. Weiter werden Hooks entweder als Pre- oder Post-Receive kategorisiert:

  • Pre-Receive Hooks werden vor bestimmten Git-Operationen ausgeführt und können eine Operation auch abbrechen, falls nötig. Damit stellen diese eine Art Wächter für Repositories dar und können verhindern, dass Teammitglieder nicht gewünschte Änderungen – oder fehlerhaften Code – ins Repository einspielen.
  • Post-Receive Hooks werden nach der Ausführung einer Operation gestartet und haben damit keinen Einfluss mehr auf den Befehl an sich. Aus diesem Grund setzt man diese Hooks zur Automatisierung von Workflows ein.

Git Hooks sind quasi kleine Roboter, die jeden Wunsch erfüllen…

Mit Git Hooks lassen sich Operationen automatisieren, zum Beispiel …

  • … die Überprüfung, ob der passende JIRA-Vorgangsschlüssel in der Commit-Nachricht enthalten ist,
  • … bestimmte Voraussetzungen für einen Merge forcieren
  • … entsprechende Benachrichtigungen via HipChat an das Team senden
  • … die Arbeitsumgebung einrichten, wenn auf einen anderen Zweig gewechselt wird.

githooks-1

Saubere Builds auf Feature-Zweigen erzwingen

Serverseitige Pre-Receive Hooks sind im Kontext von Continuous Integration besonders mächtig, denn mit ihnen kann man verhindern, dass Entwickler bestimmte Änderungen in den master-Zweig veröffentlichen. Eine Art Wächter, der den wichtigen Hauptzweig vor potenziell ungewünschten Änderungen schützt.

Entwickler sind in der Regel vernünftig genug, Änderungen mit fehlschlagenden Tests nicht in den master-Zweig zu mergen. Manchmal vergisst man dies aber. Oder mehr Änderungen wurden seit der letzten Überprüfung des Buildstatus ausgeführt. Dies geschieht vor allem recht häufig, wenn man im Team arbeitet.

Fügt man also einen serverseitigen Hook hinzu, welcher eingehende Änderungen nach master prüft, können wir mit dem Skript den aktuellen Buildstatus prüfen. Gibt es fehlgeschlagene Tests, wird der Merge abgewiesen. Atlassian stellt ein Hook-Skript für Bamboo auf Bitbucket zur Verfügung, welches als Grundlage verwendet werden kann.

Die hart verdiente Code-Abdeckung behalten

Manche Teams tun sich schwer damit, die erreichte Code-Abdeckung zu erhalten. Oft müssen die Entwickler nachträglich die Codebasis mit Tests nachrüsten, um die vorige Abdeckung wieder zu erreichen. Mit jedem Feature zu sehen, wie die Abdeckung weniger wird, ist ein frustrierendes Erlebnis. Atlassian stellt auch hierfür ein Skript zur Verfügung.

githooks-2

Das Hook-Skript prüft ebenfalls auf eingehende Merges nach master. Daraufhin kommuniziert das Skript mit dem Continuous Integration-Server, um die Code-Abdeckung auf master gegen die Abdeckung auf dem aktuellen Zweig gegenüberzustellen. Ist die Code-Abdeckung des Zweiges niedriger, wird der Merge abgewiesen.

Die meisten Continuous Integration-Server geben keine Information zur Abdeckung über ihre Remote-APIs preis. Deshalb greift das Skript auf die Berichtsdatei zurück.

Damit dies möglich ist, muss der Build so konfiguriert sein, dass der Bericht sowohl für master– als auch alle Zweig-Builds in Form eines Shared Artifact veröffentlicht wird. Sobald ein Build abgeschlossen und der Bericht veröffentlicht wurde, kann man den Bericht zur Code-Abdeckung entweder zum aktuellsten Build oder zu Builds, die die zum Merge gehörenden Commits beinhalten, abrufen.

Dies setzt natürlich voraus, dass bereits die Code-Abdeckung für alle Builds gemessen wird. Der Hook sorgt nicht auf magische Weise dafür, dass dies automatisch geschieht, sondern greift lediglich auf bereits vorhandene Daten zurück. Bamboo und Clover (Code-Abdeckung für Java und Groovy) von Atlassian werden von Haus aus unterstützt, das Skript kann aber für weitere Werkzeuge angepasst werden.

Den Status von Branch-Builds prüfen

Weil Entwickler ungern bereits fehlschlagende Zweige auschecken möchten, stellt dieser Fall ein Szenario für clientseitige Hooks dar. Ein Post-Checkout-Skript kann beispielsweise direkt im Terminal-Fenster den aktuellen Buildstatus ausgeben. Ein Beispiel steht auch hierfür zur Verfügung.

Das Skript liest die HEAD-Revision des Zweiges aus der lokalen Kopie aus und fragt beim Continuous Integration-Server an, ob hierfür bereits ein Build vorliegt – und wenn ja, ob dieser erfolgreich war.

githooks-3

Angenommen Sie möchten einen Zweig aus master heraus erstellen. Das Hook-Skript stellt die Information zur Verfügung, ob der HEAD-Commit von master erfolgreich übersetzt und damit ob es sicher ist, einen Feature-Zweig aus dem aktuellen Zustand heraus zu erstellen.

Vielleicht benachrichtigt das Hook-Skript darüber, dass ein Build fehlschlägt, obwohl master laut Wallboard übersetzt? Ein Zeichen dafür, dass Ihre lokale Kopie veraltet ist.

Dieses Skript kann Ihnen viele Kopfschmerzen ersparen. Laut Atlassian ist dieses Skript das Einzige, welches die eigenen Entwickler als absolutes Must Have bezeichnen.

Automatisierung macht das Leben einfacher

Alle hier vorgestellten Git Hooks rund um Continuous Integration funktionieren mit Atlassian Bitbucket Server, Bamboo und Clover von Haus aus. Git Hooks sind herstellerneutral und lassen sich damit auch auf andere Werkzeugketten anpassen.

Falls Sie sich dafür interessieren, wie JIRA, Bitbucket und Bamboo zusammenarbeiten können und wie sie mit Git Workflows eine robuste Continuous Delivery Pipeline erstellen können – kontaktieren Sie uns einfach. Wir helfen gerne!

Das interessiert Sie?

Dann sind wir als Atlassian Platinum Partner für Sie da.