Sonarqube

Sonarqube ist ein statisches Code-Analyse Werkzeug.

Wenn man diese Auswertung erstellen lassen möchte, sind folgende Schritte notwendig:

1. Installation bzw. Einrichtung des Sonarqube Servers
2. Vorbereitung der Konfiguration des Projekts für Sonar Analyse
3. Installation bzw. Einrichtung des Sonar Analyzers (SonarCLI)
4. Erstellung der Code Coverage und Test Result Report Dateien
5. Analyse des Projekts
6. Projekt – Dashboard

Installation des Sonarqube Servers

Um Sonarqube zu verwenden bzw. zu installieren, braucht es neben der eigentlichen Webanwendung auch noch eine Datenbank. So empfiehlt es sich, lokal dies als Docker Container zu starten:

docker run -d --name sonarqube -p 9005:9000 sonarqube:8.3.1-community

Der aufmerksame Leser erkennt, dass ich den Standardport 9000 von Sonarqube auf 9005 umgestellt habe, um nicht mit XDebug und dem Standarddebugging Remoteport in Überschneidung zu kommen.

Dieser Befehle zieht sich die entsprechende Version (8.3.1 Community) und baut alle notwendigen Docker-Container (inkl. Datenbank), um den Server zu starten:

http://localhost:9005/

Anmelden kann man sich standardmäßig mit
Username: admin / Passwort: admin
(Achtung beim allerersten Start des Docker Containers kann es einen Augenblick dauern, bis die Seite erreichbar ist)

Vorbereitung der Sonar Analyse

Um die Sonarauswertung eines Projekts vornehmen zu können, muss man in Sonar das Projekt mit einem Key anlegen.

Anschließend wählt man einen ProjectKey, den man in die sonar-project.properties einzutragen hat:

Zusätzlich braucht man ein Token:

Anschließend muss man im Projektordner die Datei sonar-project.properties anlegen.

sonar.host.url=http://localhost:9005

sonar.projectKey=coding-dojo
sonar.sources=src
sonar.tests=tests

sonar.php.coverage.reportPaths=phpunit.coverage.xml
sonar.php.tests.reportPath=phpunit.report.xml

Ich muss hier die sonar.host.url umstellen, da mein Sonarqube nicht standardmäßig unter Port 9000 zu erreichen ist.

Es gibt viele unterschiedliche Anpassungsmöglichkeiten eures Projekts. Wichtig ist, dass der Key vorher im Sonarqube Dashboard erzeugt wurde.

Installation des Sonar Scanners

Den Sonar Scanner habe ich auf diese Art und Weise installiert.

Danach lässt sich mit einer lokal installierten Version des SonarCLI das Projekt analysieren:

~/sonarcli/sonar-scanner-4.3.0.2102-linux/bin/sonar-scanner

Code Coverage und Test Results

Um die Code Coverage auch noch auswerten zu lassen, sammelt Sonarqube einfach nur die Ergebnisse von PHPUnit ein, muss diese aber eben in geeignetem Format vorliegen haben.

Für mich bedeutete dies (nach stundenlangem Suchen) folgender lokaler Befehl:

/usr/bin/php -dxdebug.coverage_enable=1 /home/malbrecht/php/Projekte/coding-dojo/vendor/phpunit/phpunit/phpunit --coverage-clover phpunit.coverage.xml --configuration /home/malbrecht/php/Projekte/coding-dojo/phpunit.xml --log-junit phpunit.report.xml

Dieser Befehl hat zwei wesentliche Optionen:

--coverage-clover phpunit.coverage.xml
--log-junit phpunit.report.xml

Diese Dateien müssen in den sonar-project.properties miteingetragen werden:

...
sonar.php.coverage.reportPaths=phpunit.coverage.xml
sonar.php.tests.reportPath=phpunit.report.xml
...

Nach einer anschließenden Analyse erhält man im Log die Ausgabe:

...
INFO: Analyzing PHPUnit test report: phpunit.report.xml
...
INFO: Analyzing PHPUnit coverage report: phpunit.coverage.xml
...

Projekt – Dashboard

Das Dashboard zeigt mir auf einen Blick, was in meinem Projekt wichtig ist. Wie ihr sehen könnt, sieht es (eigentlich) ganz gut aus.

Ich habe das Quality Gate durchschritten und habe keine Bugs, Sicherheitsprobleme oder ~lücken.
Dennoch ist meine Code Coverage trotz TDD nicht 100%. Da wurde also beim Refactoring ge“schlampt“ und ich habe 12 Code Smells, die ich gleich genauer unter die Lupe nehmen werde.

Die Bewertung der technischen Schuld in Zeitverlust von 39min ist eine Metrik von Sonarqube, um anzuzeigen, wieviel Zeit man durchschnittlich zur Behebung dieser Code Smells investieren muss.

Die Übersicht der Code Smells offenbart etwas genauer, welche Smells kritisch sind und welche einfach informationshalber angegeben werden:

Lasse ich mir beispielsweise anzeigen, warum ein bestimmter Issue ein solcher ist, erhalte ich folgende Info:

Es werden also auch potentielle Fehlerquellen von Sonarqube gezeigt, wie das Fehler umschließender geschweifter Klammern bei if…then…else Statements.

Die Einschätzung, dass es sich hierbei um einen kritischen Fehler handelt, ließe sich umkonfigurieren.
Bevor man dies jedoch haarklein selbst vornimmt, ist wahrscheinlich eine Korrektur, um zu korrektem Code zu kommen, leichter.

Wie gut die Einschätzung von Sonarqube für die Behebung meiner technischen Schuld war, sieht man daran, dass ich für die komplette Behebung der Code Smells und der Wiederherstellung der 100% Code Coverage ca. 1h gebraucht habe: