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 Depot- und Clearing-System „Alameda“) der Nationalen Abwicklungsstelle teilen.
Die Nationale Abwicklungsstelle (Gruppe der Moskauer Börse) ist eines der Schlüsselunternehmen der Finanzinfrastruktur und verwahrt und erfasst Wertpapiere russischer und ausländischer Emittenten im Wert von über 50 Billionen Rubel. Das wachsende Volumen der von der system durchgeführten Operationen sowie die kontinuierliche Erweiterung der Funktionalität erfordern die Aufrechterhaltung einer hohen Qualität des Quellcodes der Systeme. Ein Instrument zur Erreichung dieses Ziels ist der statische Code-Analyzer SonarQube. In diesem Artikel beschreiben wir unsere erfolgreiche Erfahrung mit der nahtlosen Integration des statischen Analyzers SonarQube in die bestehenden Entwicklungsprozesse unserer Abteilung.
Kurzes über die Abteilung
In unserem Kompetenzbereich befinden sich die folgenden Module: Zahlungen an Kunden der NRD, elektronischer Dokumentenverkehr (E-Dokumentation), Verarbeitung von Nachrichten des Handelsrepositories (Registrierung außerbörslicher Geschäfte), elektronische Kommunikationskanäle zwischen Kunden und NRD und vieles mehr. Insgesamt umfasst dies einen erheblichen Arbeiten an der technischen Seite der operativen Tätigkeiten. Wir arbeiten auf Basis von Anfragen. Die Anfragen der Operateure werden von Analysten bearbeitet: Sie sammeln die Anforderungen des Kunden und präsentieren uns ihre Vorstellungen, wie dies in das Programm integriert werden soll. Danach folgt das Standardverfahren: Codierung – Testen – Erprobungsbetrieb – Auslieferung des Codes an den direkten Kunden.
Warum gerade SonarQube?
Dies ist die erste Erfahrung unserer Abteilung bei der Implementierung einer Plattform zur Qualitätskontrolle des Codes – zuvor haben wir dies manuell durchgeführt und lediglich Code-Reviews gemacht. Doch das wachsende Arbeitsvolumen erfordert eine Automatisierung dieses Prozesses. Darüber hinaus gibt es im Team auch unerfahrene Mitarbeiter, die nicht ganz mit den internen Entwicklungsrichtlinien vertraut sind und eher dazu neigen, Fehler zu machen. Um die Codequalität zu überwachen, haben wir beschlossen, einen statischen Analyse-Tool einzuführen. Da SonarQube bereits in einigen Systemen der NERD verwendet wurde, fiel die Wahl schnell. Zuvor analysierten Kollegen aus anderen Abteilungen damit den Code von Mikrodiensten im System „Alameda“ (eigenes System für depot- und clearingtechnische Buchführung der NERD), in der CFT (Informationssystem zur Führung der Buchhaltung, Bilanz sowie zur Erstellung der Pflicht- und internen Berichterstattung) und in einigen anderen Systemen. Für Experimente haben wir uns entschieden, mit der kostenlosen Version von SonarQube zu beginnen. Lassen Sie uns also zu unserem Fall übergehen.
Implementierungsprozess
Wir haben:
- automatische Systembuild in TeamCity;
- der Prozess des Code-Uploads durch MergeRequest von der Feature-Branch in die Master-Branch in GitLab ist eingerichtet (Entwicklungsprozess gemäß GitHub Flow);
- SonarQube, konfiguriert zur Code-Analyse des DPO-Systems nach einem Zeitplan.
Unser Ziel: die automatisierte Code-Analyse in die CI/CD-Prozesse des DPO zu integrieren.
Einstellungen anpassen: der Prozess der automatischen Codeüberprüfung durch einen statischen Analyzer bei jedem Merge Request in den Hauptzweig.
Das Ziel ist folgendes: Sobald ein Entwickler Änderungen in den Feature-Zweig einpflegt, wird eine automatische Überprüfung auf neue Fehler im Code ausgelöst. Wenn keine Fehler vorhanden sind, wird das Einpflegen der Änderungen genehmigt; andernfalls müssen die Fehler behoben werden. Bereits in der Anfangsphase konnten wir eine bestimmte Anzahl an Fehlern im Code identifizieren. Das System bietet sehr flexible Einstellungen: Es kann so konfiguriert werden, dass es für die spezifischen Anforderungen der Entwickler sowie für jedes System und jeden Programmierstil funktioniert.
QualityGate-Konfiguration in SonarQube
Die Analyse des QualityGate ist eine Erkenntnis, die wir aus den Tiefen des Internets gewonnen haben. Anfangs verfolgten wir einen anderen, komplizierteren und in gewisser Weise ungenauen Ansatz. Zunächst führten wir zweimal Scans über SonarQube durch: wir scannten den Feature-Branch und den Branch, in den wir den Feature-Branch einpflegen wollten, und verglichen dann die Anzahl der Fehler. Diese Methode war nicht stabil und lieferte nicht immer korrekte Ergebnisse. Dann erfuhren wir, dass wir anstelle eines doppelten Durchlaufs von SonarQube ein Limit für die zulässige Anzahl von Fehlern (QualityGate) setzen und nur den Branch analysieren konnten, den wir einpflegen und vergleichen möchten.
Derzeit verwenden wir noch eine ziemlich primitive Code-Überprüfung. Es ist erwähnenswert, dass SonarQube mit einigen Programmiersprachen, einschließlich Delphi, nicht kompatibel ist. Aktuell analysieren wir nur PL/SQL-Code für unser System.
So funktioniert das:
- Wir analysieren für unser Projekt nur PL/SQL-Code.
- Im SonarQube ist das QualityGate so konfiguriert, dass die Anzahl der Fehler mit jedem Commit nicht zunimmt.
- Bei unserem ersten Scan sind 229 Fehler aufgetreten. Wenn die Anzahl der Fehler beim Commit steigt, wird der Merge nicht genehmigt.
- Nach der Behebung der Fehler kann das QualityGate neu konfiguriert werden.
- Es können auch neue Punkte zur Analyse hinzugefügt werden, wie z.B. die Testabdeckung des Codes usw.
Ablaufdiagramm:
In den Kommentaren der Skriptausführung ist zu sehen, dass die Anzahl der Fehler im Feature-Branch nicht gestiegen ist. Das bedeutet, alles ist in Ordnung.
Der Merge-Button wird verfügbar.
In den Kommentaren der Skriptausführung ist zu sehen, dass die Anzahl der Fehler im Feature-Branch den zulässigen Wert überschritten hat. Das bedeutet, es ist schlecht.
Der Merge-Button ist rot. Momentan gibt es kein Verbot, Änderungen mit fehlerhaftem Code zu pushen, jedoch liegt dies im Ermessen des zuständigen Entwicklers. Zukünftig kann das Einpflegen solcher Commits in den Hauptbranch untersagt werden.
Eigenständige Bearbeitung der Fehler
Es ist notwendig, alle vom System aufgedeckten Fehler zu überprüfen, da SonarQube nach seinen strengen Standards analysiert. Was er als Fehler ansieht, muss daher nicht unbedingt ein tatsächlicher Fehler in unserem Code sein. Deshalb ist eine Prüfung und Kennzeichnung erforderlich, um festzustellen, ob es sich wirklich um einen Fehler handelt oder ob in unseren Bedingungen keine Änderungen nötig sind. Auf diese Weise reduzieren wir die Anzahl der Fehler. Im Laufe der Zeit wird das System lernen, diese Nuancen zu verstehen.
Was wir erreicht haben
Unser Ziel war es zu verstehen, ob es sinnvoll ist, die Codeprüfung zu automatisieren. Das Ergebnis hat unsere Erwartungen übertroffen. SonarQube ermöglicht es uns, mit den von uns benötigten Programmiersprachen zu arbeiten, bietet eine vernünftige Analyse und hat das Potenzial, aus den Hinweisen der Entwickler zu lernen. Insgesamt sind wir mit unserer ersten Erfahrung mit SonarQube zufrieden und planen, in diesem Bereich weiterzuentwickeln. Wir erwarten, dass wir in Zukunft mehr Zeit und Ressourcen bei der Codeprüfung einsparen und die Qualität verbessern können, indem wir den menschlichen Faktor ausschließen. Möglicherweise werden wir im Verlauf einige Nachteile der Plattform entdecken oder, umgekehrt, uns erneut davon überzeugen, dass es sich um ein großartiges Tool mit großem Potenzial handelt.
In diesem Überblicksartikel haben wir über unsere Bekanntschaft mit dem statischen Analyse-Tool SonarQube berichtet. Wenn Sie Fragen haben, schreiben Sie bitte in die Kommentare. Wenn Sie an diesem Thema interessiert sind, werden wir in einer neuen Veröffentlichung detaillierter erläutern, wie Sie alles richtig einrichten und Code schreiben, um eine solche Prüfung durchzuführen.
Autor des Textes:
Quelle: habr.com
