Continuous Integration mit Git, Gerrit und Jenkins

Änderungen einpflegen

Nun sind alle Werkzeuge bereit und können getestet werden. Es ist daher an der Zeit, die Änderungen, die an dem lokalen Git Repository durchgeführt wurden (das neue Maven-Projekt), in den Hauptzweig zu integrieren. Dazu müssen die hinzugefügten Dateien erst einmal lokal committet und dann mittels des Git-Befehls push an den Server übertragen werden. Auch hier bietet eGit über die Option PUSH TO UPSTREAM im Kontextmenü die Funktionalität an. Durch das Pushen der Änderungen auf den Server wird die Toolchain aktiviert. Gerrit legt für den hochgeladenen Commit einen so genannten Change Request an, der alle Änderungen am Code sowie die zugehörigen Metadaten enthält. Darüber hinaus wird auf dem Jenkins-Server der Job gestartet, wodurch die aktuellste Version des Git Repositories zusammen mit der betreffenden Änderung heruntergeladen, gebaut und getestet wird. Das Ergebnis dieses Tests wird im Anschluss von Jenkins in Form eines Reviews an den Change Request angehängt und dabei das Feld Verified auf „+1“ (O.K.) oder „-1“ (fehlgeschlagen) gesetzt. In der Nachricht zu dem Review wird außerdem ein Link zu dem Ergebnis der Tests auf dem Jenkins-Server hinterlegt, sodass es möglich ist, im Falle eines Fehlers das Problem schnell zu erkennen. Schlägt der Test auf dem Jenkins-Server fehl, kann der Entwickler das Problem lokal beheben und dann den vorangegangenen Commit mittels eines amend commit ergänzen. Wird dieser wieder auf den Server geladen, legt Gerrit unter dem gleichen Change Request ein weiteres Changeset an, für das wiederum Jenkins den Job ausführt.

Wird der Change Request als stabil klassifiziert, muss im Anschluss ein Code-Review durch weitere Entwickler stattfinden. Um diese dazu aufzufordern, können dem Request weitere Gutachter hinzugefügt werden, wodurch diese eine E-Mail mit der Aufforderung und dem Link auf die entsprechende Gerrit-Seite zugesendet bekommen. Während des Review-Prozesses kann der Gutachter zeilengenaue Kommentare im Quelltext hinzufügen und eine allgemeine Zusammenfassung seiner Kommentare und Wünsche abspeichern. Dem Gutachter stehen standardmäßige numerische Bewertungen von „-2“ (sollte abgelehnt werden) bis „+2“ (wird integriert) zur Verfügung. Erfüllt der Request nicht die Ansprüche des Gutachters, formuliert dieser die Probleme und beendet sein Review mit einer Bewertung unter „+2“. Der verantwortliche Entwickler kann dann wiederum diese Kommentare lokal in seine Änderung integrieren und daraufhin durch AMEND COMMIT und PUSH TO UPSTREAM eine weitere Review-Runde starten. Nur wenn ein Change Request sowohl eine Bewertung von „+1“ in der Kategorie Verified als auch von „+2“ in der Kategorie Code Review erhalten hat, kann dieser in den Hauptzweig integriert werden. Hierzu steht dem autorisierten Nutzer beim Veröffentlichen des Reviews die Schaltfläche PUBLISH AND SUBMIT zur Verfügung. Stellt sich während des Reviews heraus, dass die Änderung verworfen werden soll, kann der Change Request auch mittels der Schaltfläche ABANDON als verworfen und geschlossen markiert werden.

Fazit

Auch wenn die Vorbereitungen zur Unterstützung einer kontinuierlichen Integration nicht unerheblich erscheinen und die Umstellung des Arbeitsablaufs zunächst ungewohnt sein kann, so überwiegen nach der initialen Konfiguration und einer kurzen Einarbeitungsphase die positiven Effekte: Nicht nur steigt die Qualität der entwickelten Software, auch kommt es durch die regelmäßigen Code-Reviews zu einem regen Austausch unter den Entwicklern. So können Kollegen ihre eigenen Entwicklungen aufgrund eines besseren Verständnisses des Gesamtprojekts leichter aufeinander abstimmen, und unerfahrene oder neue Entwickler verlieren schneller Hemmungen, an unbekannten Modulen zu arbeiten.