Sonarcloud ist eine Software zur statischen Codeanalyse. Statische Codeanalyse bedeutet, dass der Code nach gewissen Regeln basierend auf der jeweiligen Programmiersprache überprüft wird. Sonarcloud setzt diesen Prozess um, indem eine Auflistung aller Resultate der Analyse präsentiert wird und zusätzlich Verbesserungsvorschläge aufgezeigt werden.
Damit wir im Unternehmen die Software vollumfänglich nutzen können wird in diesem Artikel beschrieben, wie die Software zu benutzen ist.
Einrichten von Azure DevOps
Sonarcloud wird bei uns über die Azure DevOps Pipeline genutzt. Diese ist so konfiguriert, dass sie am Sonntagabend einen automatischen Durchlauf auslöst. Für die Einrichtung würde ich auf den folgenden Artikel verweisen. Da dieser alles vollumfänglich und vernünftig erklärt. Wichtig für uns sind folgende Stichpunkte:
- Als Buildtool sollte MSBuild genutzt werden, da derzeit noch .NET Framework Anwendungen betrieben werden. Sollten diese irgendwann wegfallen, könnte über eine Analyse über dotnet nachgedacht werden
- Bei der Einrichtung der Pipeline darf nicht vergessen werden, dass verschiedene Packages aus anderen Quellen, wie z.B. Telerik kommen. Dazu muss unter dem Punkt NuGet restore die Abhängigkeit eingetragen werden
- Sollten verschiedene Dateitypen oder Ordner nicht mit in die Analyse einbezogen werden, dann kann dies über die Additional Properties konfiguriert werden. Um alle möglichen Parameter zu sehen, sollte die Sonarcloud Dokumentation angeschaut werden.
Einrichten Account/Login
Über die
Sonarcloud Seite kann ein Account "eingerichtet" werden. Da die Software über die
Azure DevOps Funktionen genutzt wird, brauch kein gesonderter Account registriert werden. Es können die
Credentials von dem normalen
Azure DevOps Account genutzt werden.
Zum Einloggen auf die Webseite gehen und oben rechts über Login und With Azure DevOps anmelden. Wenn es die erste Anmeldung ist, dann danach dem jeweiligen Administrator bescheid geben, damit er/sie zur Organisation eingeladen werden kann und die jeweiligen Issues zugeordnet werden können.
Ablauf
Im Folgenden wird der Prozess beschrieben wie myLife Sonarcloud einsetzt.
Jedes Mitglied wird eine gewisse Anzahl an Issues innerhalb von Sonarcloud bekommen. Diese werden ausgewählt und zugewiesen anhand von den Kompetenzen und Wissensstand innerhalb der jeweiligen Projekte. Die Issues werden wöchentlich oder je nach Arbeitspensum zugewiesen. Zusätzliche Issues dürfen natürlich immer bearbeitet werden. Das Ziel ist es anfangs alle kritischen Vorkommnisse zu eliminieren. Danach werden die nächsten Probleme angegangen.
Sonarcloud ist nicht in der Lage Tickets innerhalb von Azure DevOps zu kreieren. Deshalb wird vom jeweiligen Administrator wöchentlich ein übergeordnetes Ticket in Azure DevOps angelegt, wodrin die jeweiligen Sonarcloud Tickets gesammelt werden. Dies kann dann zum einchecken von den Änderungen genutzt werden.
UI
Sobald der User sich anmeldet, wird ihm ein Dashboard angezeigt.
Dieses Dashboard stellt den Unterschied zwischen der vorherigen Version (weiß) und der aktuell hochgeladenen Version (gelb) da. Die Kategorien sollten selbsterklärend sein. Wenn dies nicht der Fall ist, dann können über die grauen Fragezeichen die Erklärungen angezeigt werden.
Für die Bearbeitung der Tickets sind vor allem die Punkte Issues und Security Hotspots wichtig. Diese beinhalten alle Tickets zu dem jeweiligen Bereich und gleichzeitig die Möglichkeit seine eigenen Issues anzuzeigen.
Bearbeitung von Tickets
Wenn ein Issue ausgewählt worden ist, gibt es die unten im Bild zu sehende Ansicht. Es gibt bei jedem Issue die Möglichkeit sich durchzulesen, wieso das ganze ein Fehler ist und wie dieser behoben werden könnte.
Der Administrator wird im vorhinein eine Auswahl an Issues zuweisen, die seiner Meinung nach einen Fehler darstellen. Es ist sehr wichtig zu beachten, dass alle Fehler analysiert werden und zu 100% als behebungswürdig eingestuft werden müssen. Sollte dies nicht der Fall sein, dann bitte ein Kommentar dem Issue zuweisen und dem Administrator wieder zuweisen. Dies gilt auch bei Unklarheiten. Die Fehler sollen nur dann behoben sein, wenn der Entwickler sich zu 100% sicher ist. Sonst soll mit dem Team Rücksprache gehalten werden.
Wenn ein Fehler behoben worden ist, wird das Issue geschlossen.