Wir möchten unsere Erfahrungen mit der Implementierung der Plattform zur kontinuierlichen Analyse und Messung der Codequalität SonarQube in die bestehenden Entwicklungsprozesse des DPO-Systems (Ergänzung zum System der Depot- und Clearingbuchhaltung „Alameda“) des Nationalen Abrechnungstaatsdepots teilen.
Das Nationale Abrechnungstaatsdepot (Gruppe der Unternehmen „Moskauer Börse“) ist eines der Schlüsselunternehmen der Finanzinfrastruktur und verwaltet und verwahrt Wertpapiere von russischen und ausländischen Emittenten im Wert von über 50 Billionen Rubel. Das wachsende Volumen der über das System abgewickelten Transaktionen sowie die kontinuierliche Erweiterung der Funktionalitäten erfordern die Aufrechterhaltung einer hohen Qualität des Quellcodes der Systeme. Ein Instrument zur Erreichung dieses Ziels ist der statische Code-Analysator SonarQube. In diesem Artikel werden wir die erfolgreiche Umsetzung des statischen Analysators SonarQube in die bestehenden Entwicklungsprozesse unserer Abteilung beschreiben.
Kurz über die Abteilung
In unserem Tätigkeitsbereich befinden sich folgende Module: Zahlungen an die Kunden des NRD, elektronischer Dokumentenaustausch (EDE), Verarbeitung von Nachrichten des Handelsdepot (Registrierung von außerbörslichen Geschäften), Kanäle der elektronischen Interaktion zwischen Kunden und NRD und vieles mehr. Im Allgemeinen betrifft dies einen großen Bereich der technischen Arbeit im operativen Geschäft. Wir arbeiten auf der Grundlage von Anfragen. Die Anfragen der Operatoren werden von Analysten bearbeitet: Sie sammeln die Anforderungen des Kunden und präsentieren uns ihre Vision, wie dies im Programm umgesetzt werden sollte. Dann folgt das Standardschema: Codeentwicklung – Testen – Betriebserprobung – Auslieferung des Codes an den produktiven Kontrakt an den direkten Kunden.
Warum gerade SonarQube?
Dies ist die erste Erfahrung unserer Abteilung bei der Implementierung einer Plattform zur Qualitätssicherung des Codes – zuvor haben wir dies manuell gemacht und nur Code-Reviews durchgeführt. Aber das wachsende Arbeitsvolumen erfordert eine Automatisierung dieses Prozesses. Außerdem gibt es im Team unerfahrene Mitarbeiter, die mit den internen Entwicklungsrichtlinien nicht ganz vertraut sind und tendenziell mehr Fehler machen. Um die Codequalität zu kontrollieren, wurde beschlossen, einen statischen Code-Analyzer einzuführen. Da SonarQube bereits in einigen Systemen der NRD verwendet wurde, musste nicht lange gewählt werden. Zuvor hatten Kollegen aus anderen Abteilungen damit den Code von Mikrodiensten im System „Alemada“ (eigenes System für Depot- und Clearingbuchhaltung der NRD), im CFT (Informationssystem für die Buchhaltung, Bilanz, Erstellung von verpflichtenden und internen Berichten) und in einigen anderen Systemen analysiert. Für die Experimente haben wir beschlossen, mit der kostenlosen Version von SonarQube zu beginnen. Lassen Sie uns also zu unserem Fall übergehen.
Implementierungsprozess
Wir haben:
- eine automatische Systembuild in TeamCity;
- einen Prozess zum Einpflegen von Code über MergeRequest vom Feature-Branch in den Master-Branch in GitLab (Entwicklungsprozess gemäß GitHub Flow) eingerichtet;
- SonarQube, konfiguriert zur Analyse des Codes für das DPO-System nach Zeitplan.
Unser Ziel: die automatische Codeanalyse in die CI/CD-Prozesse des DPO zu integrieren.
Es muss eingerichtet werden: der Prozess der automatischen Überprüfung des Codes durch den statischen Analyzer bei jedem MergeRequest in den Haupt-Branch.
Das heißt, das Zielbild ist folgendes: Sobald der Entwickler Änderungen in den Feature-Branch einpflegt, wird eine automatische Überprüfung auf neue Fehler im Code gestartet. Wenn keine Fehler vorhanden sind, wird die Annahme der Änderungen genehmigt; andernfalls müssen die Fehler behoben werden. Bereits in der Anfangsphase konnten wir eine bestimmte Anzahl von Fehlern im Code identifizieren. Das System hat sehr flexible Einstellungen: Es kann so konfiguriert werden, dass es für die spezifischen Aufgaben der Entwickler sowie für jedes System und jeden Programmierstil funktioniert.
Einrichtung des QualityGate in SonarQube
Die Analyse von QualityGate ist etwas, das wir in den Tiefen des Internets gefunden haben. Ursprünglich verwendeten wir einen anderen, komplizierteren und auf gewisse Weise nicht ganz richtigen Ansatz. Zuerst führten wir zwei Scans über SonarQube durch: Wir scannten den Feature-Branch und den Branch, in den wir den Feature-Branch integrieren wollten, und verglichen dann die Anzahl der Fehler. Diese Methode war nicht stabil und lieferte nicht immer die richtigen Ergebnisse. Dann erfuhren wir, dass wir anstelle eines doppelten Durchlaufs von SonarQube ein Limit für die zulässige Anzahl von Fehlern (QualityGate) setzen können und nur den Branch analysieren sollten, den wir hochladen und vergleichen.
Bis jetzt verwenden wir eine ziemlich primitive Codeüberprüfung. Es ist erwähnenswert, dass SonarQube mit einigen Programmiersprachen, einschließlich Delphi, nicht kompatibel ist. Derzeit analysieren wir für unser System nur PL/SQL-Code.
So funktioniert es:
- Für unser Projekt analysieren wir nur PL/SQL-Code.
- In SonarQube ist das QualityGate so eingestellt, dass die Anzahl der Fehler mit jedem Commit nicht steigt.
- Die Anzahl der Fehler beim ersten Scan betrug 229. Wenn die Fehlerzahl beim Commit steigt, wird das Merge nicht genehmigt.
- Wenn die Fehler behoben sind, kann das QualityGate neu konfiguriert werden.
- Es können auch neue Punkte zur Analyse hinzugefügt werden, beispielsweise die Testabdeckung etc.
Arbeitsweise:
In den Kommentaren der Skriptausführung ist zu sehen, dass die Anzahl der Fehler im Feature-Branch nicht gestiegen ist. Das heißt, alles ist in Ordnung.
Die Merge-Taste wird verfügbar.
In den Kommentaren der Skriptausführung ist zu sehen, dass die Anzahl der Fehler im Feature-Branch die zulässige Grenze überschritten hat. Das heißt, alles ist schlecht.
Die Merge-Taste ist rot. Derzeit gibt es kein Verbot, Änderungen am fehlerhaften Code hochzuladen, aber dies erfolgt nach Ermessen des verantwortlichen Entwicklers. Zukünftig kann es untersagt werden, solche Commits in den Hauptbranch einzufügen.
Selbstständige Arbeit an den Fehlern
Es ist nun notwendig, alle vom System identifizierten Fehler zu überprüfen, da SonarQube nach seinen strengen Standards analysiert. Was er als Fehler ansieht, könnte in unserem Code tatsächlich kein Fehler sein. Daher müssen wir überprüfen und notieren, ob es sich wirklich um einen Fehler handelt oder ob in unseren Bedingungen keine Notwendigkeit zum Korrigieren besteht. Auf diese Weise reduzieren wir die Fehlerzahl. Mit der Zeit wird das System lernen, diese Nuancen zu verstehen.
Wo sind wir gelandet
Unser Ziel war es zu verstehen, ob es sinnvoll ist, die Codeprüfung in unserem Fall zu automatisieren. Und das Ergebnis hat die Erwartungen erfüllt. SonarQube ermöglicht es uns, mit den für uns notwendigen Sprachen zu arbeiten, bietet eine recht fundierte Analyse und hat das Potenzial, von den Hinweisen der Entwickler zu lernen. Insgesamt sind wir mit unseren ersten Erfahrungen mit SonarQube zufrieden und planen, uns in diesem Bereich weiterzuentwickeln. Wir erwarten, dass wir in Zukunft mehr Zeit und Mühe bei der Codeprüfung sparen können und dass diese qualitativ hochwertiger wird, indem wir den menschlichen Faktor beseitigen. Möglicherweise werden wir im Prozess Mängel der Plattform entdecken oder uns erneut davon überzeugen, dass dies ein großartiges Tool mit großem Potenzial ist.
In diesem Überblicksartikel haben wir über unsere Bekanntschaft mit dem statischen Analysewerkzeug SonarQube berichtet. Wenn Sie Fragen haben, schreiben Sie bitte in die Kommentare. Wenn Sie sich für dieses Thema interessieren, werden wir in einer neuen Veröffentlichung bereits näher erläutern, wie man alles richtig einrichtet und Code schreibt, um eine ähnliche Prüfung durchzuführen.
Autor des Textes:
Quelle: habr.com
