Code Reviews 2.0 mit Gerrit Git und Jenkins, gerrit Browser 5, screenshot

Code Reviews 2.0 mit Gerrit, Git und Jenkins

2 Kommentare

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/<branchname> 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.

gerritBrowser4

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

gerritBrowser5

 

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 🙂

 

max.hartmann

Max Hartmann ist seit 2011 als Senior IT Consultant bei der codecentric tätig. Aufgrund seiner langjährigen Erfahrung als Entwickler und Architekt verfügt er über ein umfassendes Java-Wissen. Max unterstützt seine Kunden schwerpunktmäßig in den Bereichen Architektur und Massendatenverarbeitung. Momentan beschäftigt er sich ebenfalls mit Client-/Java-Script-Architekturen, und sein besonderes Interesse gilt zur Zeit der dynamischen JVM-Sprache Clojure.

Über 1.000 Abonnenten sind up to date!

Die neuesten Tipps, Tricks, Tools und Technologien. Jede Woche direkt in deine Inbox.

Kostenfrei anmelden und immer auf dem neuesten Stand bleiben!
(Keine Sorge, du kannst dich jederzeit abmelden.)

Hiermit willige ich in die Erhebung und Verarbeitung der vorstehenden Daten für das Empfangen des monatlichen Newsletters der codecentric AG per E-Mail ein. Ihre Einwilligung können Sie per E-Mail an datenschutz@codecentric.de, in der Informations-E-Mail selbst per Link oder an die im Impressum genannten Kontaktdaten jederzeit widerrufen. Von der Datenschutzerklärung der codecentric AG habe ich Kenntnis genommen und bestätige dies mit Absendung des Formulars.

Kommentare

  • Johannes Schumann

    6. Mai 2020 von Johannes Schumann

    Ich finde Gerrit schrecklich. Ich habe bislang gerne mit Git gearbeitet und nun haben wir in der Firma Gerrit und alles ist verrammelt. Ich weiß nicht, ob das an der unternehmenseigenen Konfiguration liegt, oder an Gerrit selbst. Es ist schwierig, zu mergen, wenn man die Rechte dafür nicht hat. Wenn in der History irgendwas ohne Change-ID ist, motzt Gerrit auch herum.

    Ich halte Gerrit für Müll. Es schafft mir mehr Arbeit, als es mir abnimmt. Kollaboration wird auch schwieriger, wenn ein wichtiger Commit nicht gereviewed und submitted wird.

    Ich höre in der Firma links und rechts alle schimpfen, was Gerrit angeht.

    Die Entscheidung, Gerrit zu benutzt, kam nicht von uns. Durch Firmenübernahmen knallen innerhalb der Firma verschiedene Welten aufeinander, und die Softwerker, die sich am besten Gehör verschafft haben, haben einen sehr bürokratisierten Ansatz, was Softwareentwicklung angeht.

    So macht es keinen Spaß. Ich mache seit zwei Wochen nichts produktives mehr, weil ich mich nur mit Gerrit-Zeugs herumplage und den Erfindungen unserer Software-Bürokraten.

    • max.hartmann

      8. Mai 2020 von max.hartmann

      Hallo,

      der Blog-Post ist natürlich schon ein paar Tage alt, aber Code-Reviews sind natürlich immer aktuell. Das ist natürlich schade, dass bei euch der Spaß wegen Gerrit so wie sich das anhört auf der Strecke geblieben ist. Ich habe Gerrit auch seit ein paar Jahren nicht mehr eingesetzt, weiß aber, dass es häufiger von großen Open-Source-Projekten eingesetzt wird.

      Tools sind logischerweise dafür da das Entwickeln zu vereinfachen und nicht das Gegenteil zu bewirken. Eigentlich ist Gerrit sehr flexibel und sollte dabei die Diskussion über Code-Änderungen unterstützen. In größeren Projekten, in denen Gerrit häufig genutzt wird, ist das auch mit Regeln verbunden. Aber das ist bei Gerrit optional und sollte in kleineren Projekten nicht so sein. Das liegt aber meines Erachtens nicht an Gerrit, sondern am Softwareentwicklungsprozess, der eigentlich zu Code-Reviews motivieren sollte.

      Wir setzen aktuell in vielen Projekten GitLab ein, das ein sehr ähnliches Konzept („Merge Requests“) wie Gerrit hat. Auch hier kann man Regeln definieren, um bei Code-Änderungen beispielsweise das direkte „committen“ auf dem master zu verbieten. „Merge Requests“ sind meines Erachtens ein bisschen leichtgewichtiger, da nicht jeder commit gereviewed werden muss wie bei Gerrit, sondern beispielsweise ein ganzes Feature.

      Gruß
      Max

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.