Technische Schulden im Griff

In den Weiten des Internets wird unter Softwareentwicklern ja immer brav über Qualität, Fehlerfreiheit, Schulden und dergleichen diskutiert. In den wenigsten Unternehmen (die ICH kenne) werden tatsächlich entsprechende Maßnahmen getroffen. Sie stehen zwar auf allen ToDo-Listen, die Einführung wird jedoch täglich prokrastiniert. Deshalb möchte ich mit diesem Beitrag zeigen, wie eines dieser hilfreichen Tools für .NET schnell aufgesetzt und eingebunden werden kann: SonarQube.

SonarQube ist ein Tool zum Messen und Erfassen von technischen Schulden. Analysiert wird auf vielfacher Ebene:

• Architektur/Design
• Coding Guidelines
• Doppelter Code
• Komplexität
• usw.

Daraus lassen sich viele hilfreiche Informationen und “Aufräumarbeiten” ableiten um die technische Qualität des Projektes zu steigern. Klingt doch gut, dann wollen wir das gleich einmal angehen.

Hinweis: In meinem Fall läuft Jenkins als Continuous Integration und wird – weiter unten – auch erweitert. Aus diesem Grund findet die Installation in meinem “Beispiel” auf dem Build-Server statt, ebenfalls wird auf das dort verfügbare Repository zugegriffen. Es gilt auch anzumerken, dass es sich empfiehlt, nicht gleich das Produktiv-System heran zu ziehen.

Installation SonarQube

Diese geht denkbar einfach vor sich. SonarQube herunter laden und entpacken. Java ist auch noch sehr hilfreich.

Wenn nicht ohnehin schon installiert bzw. gesetzt, unbedingt die Umgebungsvariable JAVA_HOME auf das bin-Verzeichnis der Java-Installation setzen.

Ist alles entpackt, kann SonarQube (in meinem Fall) via %InstallDir%/bin/windows-x86-64/StartSonar.bat gestartet werden und hört dann auf Port 9000 -> Web Interface. Bei Bedarf (sollte SonarQube tatsächlich eingesetzt werden) einfach InstallNTService.bat und StartNTService.bat verwenden, um ein Service einzurichten und gleich zu starten.

Im Standard kann man sich mit dem Benutzer admin und dem Passwort admin anmelden.

Es empfiehlt sich, das Passwort umgehend zu ändern, um hier Missbrauch vorzubeugen.

Installation Sonar Runner

Im nächsten Schritt ist der Sonar Runner zu installieren. Grundsätzlich kann SonarQube mit Maven oder Ant zusammenarbeiten, habe ich jedoch beides nicht im Einsatz. Daher werde ich direkt mit dem Sonar Runner arbeiten um die Analyse für mein Projekt zu starten.

Im Endeffekt ist auch dieses Tool nur herunter zu laden und zu entpacken. Ein wenig Konfiguration ist insofern notwendig, als dass in die Umgebungsvariable PATH der Path zur sonar-runner.bat einzutragen ist und eine weitere Umgebungsvariable SONAR_RUNNER_HOME welches auf dessen Root-Verzeichnis zeigt.

Für die Verwendung in einem .NET Umfeld ist diese Dokumentation sehr hilfreich, da für unterschiedliche Prüfung weitere (externe) Tools installiert werden müssen. Ein Aufruf des Sonar Runner gibt aber recht schnell Aufschluss darüber :)

Wer Unit Tests etc. in seinem Projekt hat, sollte dann aber gleich mal folgendes herunter laden:

• Gallio
• PartCover oder NCover
• FxCop

Damit der Sonar Runner nun seinen Dienst verrichten kann, sind noch ein paar kleinere Schritte notwendig.

Sonar Runner Konfiguration

Im Verzeichnis conf der Sonar Runner Installation findet sich eine Konfigurationsdatei. Hier sind einige Einstellungen vorzunehmen und kann dann so aussehen (Achtung, hier wurde die Datenbank verwendet, die über SonarQube mit ausgeliefert wird – dies sollte in einer Produktivumgebung geändert werden!):

#----- Default SonarQube server
sonar.host.url=localhost:9000

#----- Global database settings
sonar.jdbc.username=sonar
sonar.jdbc.password=sonar

#----- Default source code encoding
sonar.sourceEncoding=UTF-8

#----- Security (when 'sonar.forceAuthentication' is set to 'true')
sonar.login=MYUSER
sonar.password=MYPASS

Sonar Runner Properties

In das Verzeichnis der SLN-Datei muss noch eine Datei mit dem Namen sonar-project.properties. Dieses hat folgenden Inhalt (Achtung, muss entsprechend angepasst werden):

# Project identification
sonar.projectKey=com.yourcompany:PROJECTIDENTIFIER
sonar.projectVersion=1.0 PRE ALPHA
sonar.projectName=PROJECTNAME

# Info required for Sonar
sources=.
sonar.language=cs

Idealerweise dann auch gleich über das Source Control zur Verfügung stellen.

##Anbindung Jenkins CI

In meinem Falle läuft Jenkins, eine Integration wäre also äußerst hilfreich um laufend aktuelle Analysen zu erhalten und so den Verlauf prüfen zu können. Die Integrationsmöglichkeiten sind hier vielfältig. Grundsätzlich kann das Jenkins Sonar Plugin auf Jenkins installiert werden. Dieses muss dann natürlich auch entsprechend konfiguriert werden, setzt aber Maven oder Ant voraus. Wer also bereits darauf setzt, schafft eine schnelle Integration. Andernfalls, reicht es, den Sonar Runner als Build-Schritt einzubinden.

Das war es dann auch schon mit den notwendigen Installationen und Konfigurationen. Es darf “getestet” werden.

Wer auf Maven/Ant setzt, der muss den Sonar Runner nicht zwangsweise installieren, sollte sich dann aber schon ganz gut damit auskennen.

Build!

In der vorliegenden Konfiguration kann der eigentliche Build gestartet werden. Wer lieber einen manuellen Test ausführen möchte, geht dazu am Build-Server (so die Installation dort stattgefunden hat) in den jeweiligen Workspace, navigiert an die Stelle, an der das Solution-File zu finden ist und startet den Vorgang durch den Aufruf: sonar-runner.bat

Hier ist wichtig, dass die Umgebungsvariable SONAR_RUNNER_HOME (siehe oben) korrekt gesetzt ist.

Nach dem ersten erfolgreichen Durchlauf findet sich das Projekt im SonarQube Web Interface und kann begutachtet werden. Wer beispielsweise Atlassian JIRA im Einsatz hat, kann sich das JIRA Plug-In freischalten, konfigurieren und automatisch entsprechende Tasks generieren lassen, damit ja nichts verloren geht :)

Zusätzliche Konfiguration

Es bietet sich an, einen Blick in die General Settings von SonarQube zu werfen. Darin können nicht nur die einzelnen Plugins konfiguriert werden, sondern auch Ausschlusslisten etc. Gerade die Ausschlusslisten können sich anbieten, wenn bestimmte Dateien oder Verzeichnisse von der Analyse ausgeschlossen werden sollen. Viele dieser Parameter können jedoch auch in der Datei sonar-project.properties (siehe oben) pro Projekt gesetzt werden. Für weitere Informationen bitte hier weiterlesen.

Für den ungewöhnlichen Fall, dass jemand Silverlight-Projekte in seiner Solution hat, sind unbedingt die Pfade in der .NET-Konfiguration (General Settings) zu prüfen. Diese waren bei mir nicht korrekt und die notwendigen Assemblies wurden daher auch nicht gefunden. Da ist es auch nicht ausreichend, die entsprechenden Verzeichnisse einfach zu exkludieren. Schön wäre es gewesen :)

Wer sich alle möglichen Einstellungen ansehen will, nun der sollte ein wenig Zeit einplanen :)

Probleme

Mir ist es das eine oder andere Mal passiert (wieder einmal in Verbindung mit Silverlight), dass FxCop mit Fehler 9 beendet wurde. Um hier auf den Fehler zu kommen, einfach das Projekt herausfinden (steht ein paar Zeilen oberhalb der Fehlermeldung) und ins Projektverzeichnis wechseln. Dort findet sich ein Verzeichnis .sonar, welches die FxCop-Ausgabe fxcop-report.xml enthält. Dieses mit einem Editor öffnen und die Fehlermeldung beachten. Das sollte in der Regel weiterhelfen, das funktioniert übrigens für alle Fehlermeldungen, die FxCop von sich gibt. Da kann es dann aber auch schon mal vorkommen, dass Nachbesserungen am Projekt vorgenommen werden müssen.

In meinem Fall sind auch die Unit Tests nicht durchgelaufen. Alle Einstellungen die ich auf der Serverseite getroffen haben, führten leider nicht zum Ziel. Die Test-Projekte wurden zwar erkannt, aber ausgeführt wurde kein einziger. Schlussendlich habe ich diese in der sonar-project.properties vorgenommen und alles lief korrekt durch. Hier die Einstellungen die ich setzen musste:

# Gallio
sonar.gallio.safe.mode=true
sonar.dotnet.visualstudio.testProjectPattern=*Test*
sonar.gallio.runner=IsolatedProcess

Produktivbetrieb

SonarQube läuft nach der Erstinstallation auf einer H2 Datenbank. Diese ist für erste Tests ausreichend, für den Produktivbetrieb allerdings nicht. Hier empfiehlt es sich, ein anderes Datenbanksystem zu verwenden. Unterstützt wird eine ganze Reihe:

• Oracle
• MySQL
• Microsoft SQL Server
• PostgreSQL

Die Umstellung geht recht einfach:

• Datenbank (beispielsweise mit Namen sonar) am ausgewählten Datenbanksystem anlegen.
• Benutzer anlegen und Berechtigungen vergeben (muss Tabellen etc. anlegen können)
• Konfigurationsdateien anpassen
  • conf.sonar.properties
  • Wenn der Sonar Runner zum Einsatz kommt, muss auch dort die neue Datenbank-Informationen eingetragen werden
• SonarQube neu starten

Hinweis: Bestehende Daten gehen dabei verloren. Ob das mögliche Backup/Restore auch bei einem Wechsel der Datenbanken funktioniert, habe ich allerdings nicht getestet, da es sich bei mir rein um Testdaten handelte.

Fazit

Die Installation und Konfiguration könnte durchaus etwas einfacher gehen. SonarQube selbst lässt sich wunderbar installieren, bis aber dann ein etwas größeres Projekt durchläuft, muss einiges installiert und konfiguriert werden. Das erfordert dann doch recht viel Zeit. Davon sollte man sich jedoch nicht abschrecken lassen. Jedenfalls werden zahlreiche Möglichkeiten geboten, die man nutzen sollte. Wie überall gilt aber auch hier: Klein anfangen und langsam ausbauen.