Code Reviews 2.0 mit Gerrit, Git und Jenkins

Sourcecode-Reviews gehören in unseren Projekten immer häufiger zur Definition of Done. Das  kontinuierliche Überprüfen von Source-Code ist aber oft aufwendiger als man eigentlich annimmt. Der Review wird nicht selten erst durchgeführt, wenn der Source-Code bereits im produktiven Repository eingecheckt ist. Wenn dann aufgrund der Reviews noch Änderungen notwendig sind, ist das sehr aufwendig. Es bleibt einem dann nichts anderes übrig als die Änderungen von Hand aus dem Repository zu entfernen und zu checken, ob noch alles wie gewünscht funktioniert. Da lohnt es sich doch mal einen Blick auf Gerrit zu werfen, ein auf Git basierendes Code-Review-System.

Was ist Gerrit?

Gerrit ergänzt das Versionskontrollsystem Git um einen Review Prozess, mit dem Sourcecode-Änderungen im Team „gereviewed“ werden können. Jede Änderung wird dabei zunächst einmal Gerrit bekanntgemacht, dann wird ein Review-Prozess gestartet und erst nach dessen Beendigung passiert dann das Hochladen in den offiziellen Quell-Code (Abbildung 1). Auch der CI-Server Jenkins kann an dem Workflow beteiligt werden, dann wird bereits vor dem eigentlichen Review die Änderung validiert, so hat der Reviewer schon mal eine Vorabinfo über die Qualität der Anpassung.

Abbildung 1

Aufbau von Gerrit

Gerrit funktioniert wie eine Art Proxy vor dem ebenfalls bereitgestellten Git-Server. Eingecheckt wird einfach in das Git-Repository und schon wird der Review-Workflow gestartet. Danach kann der Source-Code per Browser überprüft werden. Auch das direkte Einchecken bzw. Abbrechen von Reviews ist bei ausreichender Berechtigung möglich. Das „Review-Öko-System“ besteht aus einer Web-Oberfläche, Git-Server mit HTTP- sowie SSH-Schnittstelle und ab Version 2.5 einer Rest-Schnittstelle.

Aufsetzen von Gerrit

Gerrit ist gut dokumentiert, zum schnellen Einstieg bekommt man den ersten Test-Server ohne komplizierte Authentifizierung schnell installiert. Nach der Installation kann man dann über den Browser Projekte anlegen, per Git Reviews starten und diese dann per Browser durchführen.

Nach erfolgreichem Login kann man über Projects->Create New Project ein neues Projekt anlegen, damit wird ein Gerrit-Projekt inkl. Git-Repository angelegt. Mehr Details zur Installation und Konfiguration von Gerrit findet sich in der Gerrit-Doku.

Änderungen Gerrit bekanntmachen

Per Konvention werden alle Änderungen für einen bestimmten Branch nach refs/for/ gepushed, dann startet automatisch der Reviewprozess. Wenn die Überprüfung abgeschlossen ist, wird die Änderung in den Zielbranch gemerged. Falls keine Konflikte bei der Zusammenführung auftreten passiert dies automatisiert.

Jetzt aber los: Ein kleines Beispielprojekt

Das Beispielprojekt habe ich bereits in Gerrit angelegt, also kanns losgehen. Dazu benötigen wir nur eine Kommandozeile, die Git spricht.

Als erstes klonen wir das Repository, fügen ein Datei hinzu (test.txt) und pushen diese nach refs/for/master:

Gerrit hat die Änderung bereits registriert:

Nach klick auf die Änderung sehen wir mehr Details, u.a. Basisinformationen, Review-Status, Abhängigkeiten, beteiligte Dateien und Kommentare. Außerdem wurde die Änderung bereits validiert, das hat Jenkins bereits gemacht (Infos zur Jenkins-Konfiguration hier ):

Jenkins hat dazu ebenfalls Kommentare hinterlassen:

Als nächstes schauen wir uns die Änderung einmal genauer an, dazu klicken wir einfach auf die Datei text.txt und die Änderungen werden angezeigt:

Kommentare zur Änderung werden einfach per Doppelklick verfasst:

Zum Abschluss müssen wir dem Review jetzt nur noch unser Gesamturteil verpassen. Dazu gehen wir zurück zur Änderung und klicken auf Review.

Das Urteil wird nach folgendem Punktesystem vergeben:

• +2: Änderung genehmigt und kann in den Zielbranch gemerged werden
• +1: Änderung gefällt, sollte aber noch von einem weiteren rereviewed werden
• 0: keine Meihnung
• -1: Änderung gefällt nicht so sehr, sollte also nicht gemerged werden
• -2: Änderung abgelehnt und kann auf keinen Fall in den Zielbranch gemerged werden

Im Standard-Workflow werden +1, -1 als Empfehlungen, während +2,-2 als Genehmigung bzw. Ablehnung verstanden werden. Die Punktevergabe kann man in Gerrit berechtigen (Berechtigungs-Doku).

Ein Klick auf Publish veröffentlicht das Ganze, bei ausreichender Berechtigung kann die Änderung auch direkt gemerged werden, Publish and Submit. Wir submitten direkt.

Die Änderung wird direkt in den Zielbranch (hier: master) gemerged und nochmal in der Übersicht angezeigt:

Weitere Features von Gerrit

• Berechtigung von Repository- sowie Review-Funktionen, beispielsweise können bestimmte Benutzer den Review-Prozess auch überspringen und direkt in den Zielbranch pushen. Das macht Gerrit sehr flexibel, im einfachsten Fall benutzt man Gerrit nur als Git-Server. Auch das Abbrechen eines Reviews ist möglich, wenn ein berechtigter Benutzer eine Änderung im Nachhinein direkt pushed, interpretiert Gerrit das als: Der Review scheint nicht mehr benötigt zu werden.
• Replikation mit anderen Git-Repositories. Hiermit kann man seinen Workflow um entfernte Repositories erweitern. Denkbar wäre beispielsweise eine Integration von Git-Hub. Alle Änderungen, die für Gut befunden werden, werden automatisch repliziert.
• SSH-Schittstelle: wie oben beschrieben bietet Gerrit auch eine SSH-Schnittstelle an. Diese ist nicht auf die Git-Features beschränkt, auch den Review selber kann man direkt per Shell machen (Gerrit-Commandline-Tools).
• Eclipse-Integration: auch die Eclipse-Integration ist sehr ausgereift, sowohl das EGit-Plugin als auch ein Gerrit-Mylyn-Connector machen das Arbeiten mit Gerrit sehr einfach.

Fazit

Mein erster Eindruck: Gerrit kann was 🙂 Besonders die Integration mit Git ist sehr gelungen, man braucht außer Git nicht viel zu kennen. Man checkt einfach ein und schon wird der Review-Prozess gestartet. Auch die Anwendung mit Eclipse ist beeindruckend und wird sich vermutlich noch verbessern, da Eclipse selber auch Gerrit verwendet (Eclipse-Gerrit ).

Die Integration mit Jenkins macht ebenfalls Spaß, es wird direkt der richtige Code ausgecheckt und validiert. Es ist nicht mehr notwendig mehrere Jobs für ein und dasselbe Projekt zu konfigurieren. Das Jenkins-Plugin sucht sich selbstständig das zu prüfende Changeset im richtigen Branch heraus.

Einschränkend muss man nur sagen, dass Gerrit nur mit Git funktioniert. Man hat ja nicht in jedem Projekt die freie Wahl des Versionskontrollsystems 🙁 Wenn man allerdings bereits mit Git arbeitet, ist der Weg zu Gerrit nicht mehr allzuweit.

Aus Projektsicht muß man sich natürlich fragen, will ich wirklich für jede Änderung an der Code-Basis ein Review durchführen? Der Vorteil von Gerrit ist, dass es nicht zum Reviewen verpflichtet, sondern auch als Git-Repository verwendet werden kann – wie für den schnellen Einstieg gemacht 🙂