Code-Reviews bilden ein wichtiges Werkzeug im Prozess der Software-Entwicklung, um eine bestmögliche Code-Qualität sicherzustellen. Sie  fördern den Austausch im Team über die Code-Struktur, den Stil und die Architektur, und natürlich dienen sie dazu, sowohl Optimierungspotenziale als auch Schwachstellen aufzudecken.

In diesem Artikel zeigen wir, wie Atlassians Git-Repository-Manager Stash in Kombination mit SonarQube, einem ausgereiften Tool zur statischen Code-Analyse, und dem Sonar-Plugin für Stash Code-Reviews und damit den Entwicklungsprozess effektiv unterstützen kann. (SonarQube haben wir in unserem Beitrag "Code-Qualität optimieren mit SonarQube und Bamboo" schon ausführlicher eingeführt.)

Um die folgenden Beispiele aktiv reproduzieren zu können, sollte eine lauffähige SonarQube-Instanz vorhanden sein. (Eine Einrichtung in wenigen Minuten haben wir hier demonstriert.)

Sonar-Plugin-Installation

Zunächst müssen wir das kommerzielle Sonar-Plugin für Stash von Mibex Software installieren. Dieses steht auf dem Atlassian Marketplace zur Verfügung und kann direkt über den Stash-Administrationsbereich heruntergeladen und verfügbar gemacht werden.

Installation des Sonar-Plugins für Stash

Nach der Installation beginnt automatisch die 30-tägige kostenfreie Testphase, nach deren Ablauf das Plugin regulär lizenziert werden muss.

Sonar-Plugin-Installation und -Lizenzierung abgeschlossen

Konfiguration des Sonar-Plugins

Um Stash und SonarQube zu integrieren, müssen wir Stash in den Plugin-Einstellungen zunächst Adresse und Zugangsdaten der vorhandenen SonarQube Instanz mitteilen.

Konfiguration der Sonar-Anbindung in den Plugin-Einstellungen

Repository-Konfiguration

In den Repository-Einstellungen in Stash müssen wir unser Sonar-Projekt für unser spezifisches Git-Repo nun konfigurieren. Dazu stehen uns diverse Optionen zur Verfügung, die wir nachfolgend erläutern.

Sonar-Projektkonfiguration
Wenn das Projekt bereits in Sonar vorhanden ist, lässt es sich hier per Select-Box auswählen. Alternativ können wir den Projekt-Basisschlüssel manuell eingeben. Bei einem Maven-basierten Projekt ist das Format groupId:artifactId Standard.

Branches werden in Sonar in separaten Projekten abgelegt. So bildet für unseren Anwendungsfall der Branch-Name das Suffix und ergibt zusammen mit dem Basisschlüssel den Namen des Sonar-Projekts, das wir in Stash referenzieren.

Wird eine ältere Sonar-Version (unter 5.0) verwendet, müssen Zeichen wie "/" aus dem Branch-Namen gefiltert werden; das ersatzweise verwendete Zeichen lässt sich hier ebenfalls konfigurieren. Falls wir Sonar durch ein Build-Tool ansteuern, müssen wir dies berücksichtigen und dort beim Ausführen des Sonar-Goals ebenfalls diese Filterung anwenden.

Außerdem können wir das Löschen des Sonar-Projekts für den Fall konfigurieren, dass wir das dazugehörige Repository in Stash entfernen.

Sonar-Projektkonfiguration in den Stash-Repository-Einstellungen

Anzeige von Sonar-Issues konfigurieren
Hier können wir einstellen, ob Sonar-Issues in der Diff-Anzeige eines Pull-Requests angezeigt werden sollen und ggf. ab welchem Härtegrad.

Konfiguration der Issue-Integration in Pull-Requests in der Stash-Repository-Administration

Anzeige von Code-Dopplungen festlegen
Hier kann konfiguriert werden, ob Code-Doppelungen in der Diff-Ansicht eines Pull-Requests angezeigt werden sollen. (Bedingung ist, dass SonarQube in der Version 4.4 oder höher zum Einsatz kommt.)

Konfiguration der Anzeige von Code-Doppelungen im Pull-Requests

Anzeige fehlender Testabdeckung konfigurieren
Unter dieser Option können wir definieren, dass in der Diff-Anzeige eines Pull-Requests Codezeilen ohne entsprechende Testabdeckung markiert werden. Dabei lässt sich festlegen, ob eine fehlende Abdeckung durch Unit-Tests, durch Integration-Tests oder durch beide Testgattungen berücksichtigt werden soll.

Konfiguration der Anzeige fehlender Testabdeckung im Pull-Request

Anzeige der Sonar-Statistik definieren
Hier lässt sich die Anzeige der Sonar-Statistiken für die Übersicht eines Pull-Requests aktivieren. Ist diese Option aktiv, gibt Sonar Statistiken aus, die Rückschlüsse auf die qualitative Entwicklung zwischen dem Branch des Pull-Requests und seinem Ziel zulassen (z.B. Feature-Branch feature/implement-sth und Ziel-Branch master).

Die folgenden Informationen werden im Vergleich dargestellt:

• Anzahl technischer Schuld (Technical Debts)
• Anzahl der Probleme insgesamt (Issues)
• Anzahl der Code-Doppelungen (Duplicate lines)
• Schwellenwert für die Testabdeckung (Test coverage threshold)

Konfiguration der Anzeige vergleichender Statistiken für die Pull-Request-Übersicht

Wie diese Statistik dann aussieht, zeigt das Beispiel unten.

Konfiguration der Freigabekriterien
In den Einstellungen für Merge-Checks können wir die qualitativen Grenzen definieren, bei deren Überschreitung das Mergen von Pull-Requests unterbunden wird. Die folgenden Grenzen lassen sich festlegen:

• Prozentuale Erhöhung der technischen Schuld (Technical Debt)
• Maximale Anzahl neuer Probleme (Issues) und deren Härtegrad
• Prozentuale Erhöhung doppelter Codezeilen
• Prozentuale Erhöhung des Schwellwerts der Testabdeckung (Test coverage threshold)

Konfiguration qualitativer Bedingungen für das Mergen eines Pull-Requests

Integrationsbeispiel

Nachdem die Stash-SonarQube-Integration unseren Anforderungen entsprechend eingerichtet ist, wollen wir für unser einfaches Demoprojekt einen Pull-Request absetzen und den Code dann reviewen.

Repository mit Branch-Informationen auf SonarQube übertragen
Bei unserem Beispiel handelt es sich um ein simples Maven-Projekt. Da wir mit Stash arbeiten, ist die Versionskontrolle natürlich Git; der master-branch ist unser Basis-Branch. Obwohl wir eine neuere Sonar-Version verwenden, werden wir auch die Filterung des Branch-Namens demonstrieren.

Den master-Branch können wir mit dem folgenden Befehl zu Sonar übertragen:

mvn sonar:sonar -Dsonar.branch=master

Dann erstellen wir einen Feature-Branch mit dem Namen feature/comparable-users und integrieren absichtlich Fehler. Diesen Feature-Branch pushen wir und übertragen ihn im Anschluss daran mit dem folgenden Kommando auf Sonar:

mvn sonar:sonar -Dsonar.branch=feature_comparable-users

Damit sollten beide Branches wie in der Ansicht unten als Projekt in Sonar vorliegen. (Wir sehen bereits: Der Feature-Branch weist mehr Probleme auf als der master-Branch.)

Übersicht beider Branches eines Projekts in SonarQube

Pull-Request erstellen
Nun stellen wir einen Pull-Request zur Integration des Feature-Branchs in den master:

Erstellung eines neuen Pull-Requests in Stash zur Integration eines Feature-Branchs in den master-Branch

In der Rolle als Reviewer öffnen wir anschließend den Pull-Request und können bereits (in der kleinen Box rechts) die qualitative Abweichung des Feature-Branches vom master erkennen:

Anzeige der SonarQube-Statistiken in der Pull-Request-Übersicht

Ruft der Reviewer nun die Diff-Ansicht für den Pull-Request auf, kann er per Klick auf das Sonar-Icon eine Übersicht mit den erkannten Sonar-Issues und den entsprechenden Warnhinweisen aufrufen:

Anzeige aktueller SonarQube-Issues in der Diff-Ansicht für einen Pull-Request

Ein Klick auf das rote Hinweis-Icon in der Diff-Ansicht zeigt die spezifische Warnung für die ausgewählte Codezeile an:

Anzeige konkreter Probleme in der Diff-Ansicht eines Pull-Requests

Wir sehen: Durch integrierte Code-Issues in Pull-Requests nehmen Stash und SonarQube im Zusammenspiel dem Reviewer einiges an Arbeit ab und unterstützen ihn dabei, Fehler systematisch aufzuspüren. Die Visualisierung in der Diff-Ansicht ist intuitiv, Sonar-Metriken werden direkt im Pull-Request angezeigt, und Merge-Checks helfen sicherzustellen, dass nur hochqualitativer Code gemergt werden kann. Eine praktische Lösung für effektive Code-Reviews.

Ihr Partner für individuelle Software-Projekte

Planen Sie bereits ein konkretes Software-Projekt? Oder gibt es bestimmte Prozesse in Ihrem Unternehmen, die Ihnen schon lange Kopfzerbrechen bereiten? Bremst ein System oder eine Schnittstelle Ihre Mitarbeiter auf der einen oder Ihre Kunden auf der anderen Seite aus? Dann sprechen Sie mit uns darüber! Wir freuen uns darauf, gemeinsam eine individuelle Lösung zu entwickeln – bei höchster Qualität und voller Kostenkontrolle. Wir legen größten Wert auf Erweiterbarkeit, Performanz, Skalierbarkeit, Plattformunabhängigkeit und Testbarkeit und schaffen individuelle High-End-Software-Lösungen, die sich auch im Nachhinein flexibel ausbauen und verändern lassen.

Weiterführende Infos

Individuelle Software-Entwicklung: Workflows, Branching-Modelle und Continuous Delivery
Code-Qualität optimieren mit SonarQube und Bamboo
Code-Coverage-Metriken mit Bamboo und Clover
Vorgehen nach Scrum: Die beste Wahl für den Kunden, die Agentur – und das Produkt
Was agile Software-Projekte dem Kunden bringen

Mehr über die Creative-Commons-Lizenz erfahren