Automatische Code Reviews mit SonarQube und Jenkins Teil 1/2

Eine gute Möglichkeit zur Verbesserung der Codequalität ist das Code Review. Oft schrecken Teams vor Code Reviews zurück, weil sie viel Zeit in Anspruch nehmen. Eine Alternative könnte ein automatisches Code-Review-System sein, das Ihren Code auf die Einhaltung bestimmter Metriken und Regeln überprüft. Allerdings sollten sich Entwicklungsteams nicht ausschließlich auf einen automatischen Prozess verlassen, da funktionale und logische Aspekte des Codes nur schwer durch Metriken und Regeln überprüft werden können. Ein guter Mittelweg ist eine Kombination aus einem automatischen und einem Peer-Review-Prozess als Gesamtüberprüfungsprozess. Ein zusätzliches Peer-Review bietet auch Vorteile wie den Austausch von Wissen und die Steigerung der allgemeinen Codequalität des Teams. Außerdem liefert das automatische Code Review hilfreiche Informationen für die Reviewer im Peer-Review-Prozess.

Mit dem [Cloudogu EcoSystem](https://cloudogu.com/de/glossar/cloudogu-ecosystem/ "Cloudogu EcoSystem | Cloudogu Glossar) können Sie ein solches System auf Basis von SCM-Manager, Jenkins und SonarQube realisieren. Die Installation der hier genannten Plugins geschieht mithilfe des Cloudogu EcoSystems automatisch. In diesem ersten Teil zeigen wir Ihnen, wie Sie Peer Reviews in SCM-Manager durchführen können sowie die Konfiguration von Jenkins. Im zweiten Teil geht es um die Erweiterung des Systems durch die Integration von SonarQube. Hinweis: Grundsätzlich bietet SCM-Manager die Möglichkeit eines rein automatischen Code Reviews, dies wird jedoch nicht empfohlen.

Peer Reviews mit SCM-Manager

Um Pull Requests erstellen und bearbeiten zu können und so effektiv mit anderen Entwickelnden zusammenzuarbeiten, muss das Review Plugin installiert sein. Das Plugin ermöglicht es Ihnen, Pull Requests zu erstellen und zu ändern. Ein Pull Request kann entweder über die Kommandozeile oder direkt in SCM-Manager erstellt werden. Die Pull Requests sind eine großartige Möglichkeit, andere Entwickelnde darüber zu informieren, dass der Code für das Review bereit ist, und gleichzeitig alle relevanten Informationen für die Reviewer an einem Ort zu sammeln. Reviewer können dem Pull Request manuell hinzugefügt werden oder in den Pull Request Einstellungen als Standard-Reviewerkonfiguriert werden, die dann in neuen Pull Requests als Reviewer eingetragen werden. Die Reviewer können per E-Mail über den Status der Pull Requests (Erstellung, Änderungen, etc.) informiert werden. Die Reviewer können dann den Pull Request kommentieren und je nach Review die Pull Requests entweder zusammenführen oder ablehnen. Es gibt auch viele Anpassungsoptionen, um den Review Prozess für jeden Teamworkflow zu individualisieren, z. B. Standard Aufgaben, Labels, Vorlagen für den Merge Commit usw.

Zusätzlich können mit Hilfe des CI Plugin Continuous-Integration-Systeme an SCM-Manager angebunden und beim Pull Request angezeigt werden. Dies bietet die Möglichkeit, Peer Reviews mit automatischen Reviews durch Jenkins und SonarQube zu kombinieren, da diese mit der Erstellung eines Pull Requests oder einem neuen Commit zu einem bestehenden Pull Request angestoßen werden. Die Ergebnisse werden direkt im Pull Request in der Analyse-Statusleiste angezeigt und können von den Reviewern berücksichtigt werden. Zusätzliche Regeln, wie z.B. die Anzahl der Freigaben, können ebenfalls erzwungen werden und werden im Pull Request in der Workflow-Statusleiste angezeigt.

Code Reviews basierend auf Jenkins und Sonarqube

Das automatische Code-Review-System ist so konzipiert, dass es schnelles Feedback nach einem Push zu einem bestehenden Pull-Request oder nach der Erstellung eines neuen PRs liefert. Es prüft, ob der Code gebaut werden kann oder nicht, sowie den Erfolg von Unit-Tests. Durch die Integration von SonarQube können Sie individuelle Regeln und Metriken definieren, die erfüllt sein müssen, um Änderungen im Main Branch zu speichern. In diesem System verwenden Entwickelnde eigene Branches für Änderungen und nur wenn es keine Regelverletzung gibt (d.h. das Projekt kann gebaut werden), können die Änderungen vom Reviewer auf Knopfdruck in dem Integrationszweig zusammengeführt werden.

Nach einem Push in das Repository triggert SCM-Manager einen Build im Jenkins. Jenkins wiederum führt lokal die Änderungen aus dem Entwicklungs-Branch in den Main Branch zusammen und baut das Projekt. Der Status des Builds wird im Pull Request angezeigt. Entwickelnde erhalten so die Information, ob es Probleme gab und der Code überarbeitet werden muss oder der PR bereits gemerged werden kann.

Das automatische Code-Review-System kann für Git- und Mercurial- als auch Subversion-Repositories verwendet werden.

Implementation für SCM-Manager und Jenkins

Um diesen automatischen Code-Review-Prozess zu implementieren, ist es notwendig, die Konfiguration von SCM-Manager und Jenkins an einigen Stellen anzupassen.

SCM-Manager Konfiguration

Um die Kommunikation zwischen SCM-Manager und Jenkins zu realisieren, müssen sowohl das CI-Plugin als auch das Jenkins-Plugin installiert sein und Jenkins sollte das SCM-Manager-Plugin installiert haben.

In SCM-Manager selbst kann sowohl global in den Einstellungen unter dem Tab Administration der Jenkins-Server konfiguriert werden als auch pro Repository in den jeweiligen Einstellungen.

Nach dieser Konfiguration ist SCM-Manager für den automatischen Code-Review-Prozess vorbereitet.

Jenkins Konfiguration

Jobs in Jenkins können entweder über die Benutzeroberfläche oder über ein Jenkinsfile konfiguriert werden. Dieses kann u.a. aus einem Build-Trigger, dem eigentlichen Build, der Konfiguration der Codeanalyse und dem Deployment besteht.

Ein neuer Jenkins-Job kann unter dem Punkt Element anlegen in der linken Menüleiste erstellt werden. Damit die Kommunikation zwischen SCM-Manager und Jenkins in Form des CI-Status optimal funktioniert, sollte je nach Bedarf entweder Multibranch Pipeline oder Organizational Folder ausgewählt und konfiguriert werden. In der Multibranch Pipeline lässt sich die Quelle der Branches unter Branch Sources auswählen, im Organizational Folder findet sich eine entsprechende Einstellung unter Project Sources. Für alle anderen Projektformen ist eine Anzeige des Build-Status am PR nicht "out of the box" möglich.

Das war's mit der Grundkonfiguration von Jenkins zur Implementierung der automatischen Code Reviews.

Erweiterung mit SonarQube

Durch diese Konfiguration von SCM-Manager und Jenkins erhalten Entwickelnde eine Rückmeldung über die von ihm vorgenommenen Änderungen, und der Main Branch wird vor Änderungen geschützt, durch die ein Build kaputt gehen würde. Es ist möglich, die automatischen Code Reviews zu erweitern, indem man Metriken der SonarQube-Analyse als Anforderung hinzufügt, die erfüllt sein müssen, um Änderungen in den Main Branch einzubinden. Die notwendige Konfiguration zeigen wir im zweiten Teil dieses Beitrags.