In früheren Artikeln haben wir verschiedene Testverfahren gesehen, mit denen wir die Qualität und Korrektheit des zu liefernden Endprodukts sicherstellen können. In diesem Artikel werden wir über SonarQube sprechen, ein Tool, mit dem wir auch intern die Qualität sicherstellen können.
Wir können also kontrollieren, ob der Entwicklungsprozess, die verwendete Architektur oder die eingesetzten Algorithmen einer geeigneten Struktur folgen, einem Muster, welches uns eine einfache Pflege des Produkts ermöglicht.
Was ist SonarQube?
SonarQube ist eines der meistgenutzten Tools, um Codes zu überprüfen, Bugs, Schwachstellen und andere Probleme in unserem Projekt zu erkennen. Es ermöglicht die Analyse eines Codes, der in den gängigsten Programmiersprachen geschrieben wurde (Java, PHP, JavaScript, C#, HTML, etc.).
SonarQube wird als eine weitere Datei in das zu analysierende Projekt integriert, und wenn die Pipeline, in der die Tasks gestartet werden, richtig konfiguriert ist, wird die Code-Inspektion jedes Mal automatisch durchgeführt, wenn wir eine Änderung in irgendeinem Teil des Projekts vornehmen.
Wie man in dem Bild sehen kann ist das typische Szenario, in welcher man die Nützlichkeit am besten verstehen kann, eins mit drei klaren Phasen:
- Entwicklung – Der Code wird von den Entwicklern im Repository aktualisiert. Bevor sie den SonarQube-Dienst mit der Analyse der Änderungen beauftragen, können sie dank des SonarLint-Tools, das in die IDEs integriert werden kann, sofortiges Feedback erhalten.
- CI/CD – Wenn die neuen Änderungen in das Repository aufgenommen werden, prüfen und erstellen die Continuous Integration Tools den Code und führen die Tests aus. Dann wird der SonarQube-Scanner aufgerufen, um die Ergebnisse einiger dieser Tests und den Code als solchen zu analysieren.
- SonarQube-Plattform – Sobald die Analyse des Projekts abgeschlossen ist, werden die Ergebnisse in der Plattform gespeichert und abhängig von den konfigurierten Qualitätsbedingungen können die Teammitglieder informiert werden, wenn sie einen Mangel beheben müssen.
Für die verschiedenen Projekte, die bei WATA Factory, durchgeführt werden, haben wir uns für die Community-Edition entschieden, die frei und Open Source ist. Es gibt jedoch auch kostenpflichtige Alternativen, die die Installation und Wartung des SonarQube-Dienstes durch dasselbe Unternehmen erleichtern. Die Community-Version kann auf zwei Arten installiert werden:
- Lokal – Der Entwickler kann den SonarQube-Dienst auf seinem Localhost einrichten, um seinen Code analysieren zu können, ohne ihn auf einem externen oder entfernten Server hosten zu müssen.
- Remote – Der SonarQube-Dienst wird auf einem Remote-Server gehostet, auf den man mittels vom Dienstadministrator generierter Anmeldeinformationen zugreifen kann.
Je nach Bedarf und Größe des Projekts (Mitglieder, Ressourcen oder Dienstleistungen, die in Anspruch genommen werden müssen) kann man die am besten geeignete Option wählen.
Allgemeine Konzepte
Um ein wenig mehr über die Relevanz der Verwendung dieses Tools zu verstehen, werden wir die allgemeinen Konzepte, welche auf der Plattform erscheinen, detailliert erläutern:
- Benutzer und Gruppen: Wie in jeder Umgebung können wir Benutzer definieren, die in Gruppen verwaltet werden. Jeder dieser Benutzer verfügt über eine Reihe von Berechtigungen, die ihnen ermöglichen die Analyse eines Projekts anzufordern, falsch positive Ergebnisse der durchgeführten Analyse zu validieren oder sogar zu stornieren.
- Projekte: Um die Analyse unseres Codes durchzuführen, müssen wir ein Projekt mit den notwendigen Parametern, die unser Softwareprojekt identifizieren, auf der Plattform erstellen. Diese Parameter sollten, abhängig von der Sprache, die wir in unserem Projekt verwenden, auf die eine oder andere Weise angegeben werden. Innerhalb dieser Projekte finden wir die Analyse der einzelnen Projekte, die folgende Daten enthält:
- Bugs: Fehler im Code, die so schnell wie möglich behoben werden müssen
- Schwachstellen: Stellen im Code, die offen für externe Angriffe sind und die Integrität und Sicherheit des Projekts gefährden können.
- Hotspots: Bereiche des Codes, die überprüft werden sollten, um größere Probleme zu vermeiden, sie müssen nicht unbedingt die Sicherheit des Projekts gefährden.
- Code Smells: Elemente, die den Code unverständlich oder schwer wartbar machen.
- Abdeckung: Aus den Berichten der ausgeführten Unit-Tests importiert SonarQube die Ergebnisse und zeigt die Abdeckung an.
- Duplikate: Anzahl der erkannten duplizierten Blöcke, Dateien und Zeilen.
- Gesamtzeilen: Gesamte Anzahl der Codezeilen im Projekt.
- Sprachen: Programmiersprachen, die im Projekt verwendet werden.
- Aktueller Status: Failed/Passed, abhängig von den im zugehörigen Qualitätsprofil festgelegten Werten.
- Tags: Tags, die dem Projekt zugewiesen wurden.
- Zeitpunkt der letzten Analyse: Aufzeichnung jeder durchgeführten Analyse.
- Qualitätsprofile: Sie hängen direkt von den in den Quality Gates festgelegten Bedingungen ab, welche die Regeln angeben, die in jeder der in SonarQube verfügbaren Sprachen befolgt werden müssen. Die Bedingungen der Qualitätsprofile spiegeln die Grenzen der Mindestabdeckung, der duplizierten Zeilen, des Sicherheitsindex oder des Wartbarkeitsindex wider.
Wie wir sehen können, sind der Bericht und die generierten Informationen sehr umfangreich, was uns einen sehr genauen Überblick über den Status unseres Projekts ermöglicht.
Bei WATA Factory haben wir mit SonarQube ein weiteres Werkzeug etabliert, welches die Verbesserung der Codequalität und auch ein indirektes Lernen bei den Entwicklern ermöglicht. Denn mit jedem der Berichte lernt man, welche schlechten Praktiken zu vermeiden sind und wie man sie mit den Vorschlägen, die das gleiche Tool anbietet, dank der in den Quality Gates definierten Regeln lösen kann In zukünftigen Artikeln werden wir sehen, wie wir unser Projekt konfigurieren, um es mit SonarQube automatisch aus einer Pipeline heraus analysieren zu können.
