Wir möchten unsere Erfahrungen bei der Implementierung einer Plattform zur kontinuierlichen Analyse und Messung der Qualität des SonarQube-Codes in die bestehenden Prozesse zur Entwicklung des DPO-Systems (eine Ergänzung zum Alameda-Verwahrungs- und Clearing-Buchhaltungssystem) des National Settlement Depository teilen.
Das National Settlement Depository (Moscow Exchange Group of Companies) ist eines der wichtigsten Finanzinfrastrukturunternehmen, das Wertpapiere russischer und ausländischer Emittenten im Wert von mehr als 50 Billionen Rubel lagert und verbucht. Das wachsende Volumen der vom System ausgeführten Operationen sowie die kontinuierliche Steigerung der Funktionalität erfordern die Aufrechterhaltung einer hohen Qualität des Quellcodes der Systeme. Eines der Tools, um dieses Ziel zu erreichen, ist der statische Analysator SonarQube. In diesem Artikel beschreiben wir die erfolgreiche Erfahrung der nahtlosen Implementierung des statischen Analysators SonarQube in die bestehenden Entwicklungsprozesse unserer Abteilung.
Kurz zur Abteilung
Unsere Kompetenz umfasst folgende Module: Zahlungen an NSD-Kunden, elektronisches Dokumentenmanagement (EDF), Verarbeitung von Transaktionsregisternachrichten (Registrierung außerbörslicher Transaktionen), elektronische Interaktionskanäle zwischen Kunden und NSD und vieles mehr. Im Allgemeinen gibt es einen großen Arbeitsaufwand auf der technischen Seite des Betriebs. Wir arbeiten auf Antragsbasis. Bewerbungen von Kassierern werden von Analysten bearbeitet: Sie sammeln Kundenanforderungen und präsentieren uns ihre Vorstellung davon, wie sie in das Programm passen sollten. Weiter das Standardschema: Codeentwicklung – Testen – Probebetrieb – Übergabe des Codes an den Produktivkreislauf an den Direktkunden.
Warum SonarQube?
Dies ist die erste Erfahrung unserer Abteilung bei der Implementierung einer Plattform zur Codequalitätskontrolle – zuvor haben wir dies manuell durchgeführt, nur Codeüberprüfung. Doch das wachsende Arbeitsvolumen erfordert eine Automatisierung dieses Prozesses. Darüber hinaus gibt es im Team auch unerfahrene Mitarbeiter, die mit den internen Entwicklungsvorschriften nicht ganz vertraut sind und tendenziell häufiger Fehler machen. Um die Qualität des Codes zu kontrollieren, wurde beschlossen, einen statischen Analysator zu implementieren. Da SonarQube bereits in einigen NSD-Systemen zum Einsatz kam, dauerte die Entscheidung nicht lange. Zuvor analysierten Kollegen aus anderen Abteilungen damit den Code von Microservices im Alameda-System (NSDs eigenes Depot- und Clearing-Buchhaltungssystem), im CFT (Informationssystem für Buchhaltung, Saldo, Vorbereitung der obligatorischen und internen Berichterstattung) und in einigen anderen Systeme. Um zu experimentieren, haben wir uns entschieden, mit der kostenlosen Version von SonarQube zu beginnen. Kommen wir also zu unserem Fall.
Umsetzungsprozess
Hier ist unser Land:
- automatische Montage des Systems in TeamCity;
- Richten Sie den Prozess zum Hochladen von Code über MergeRequest von einem Feature-Branch zum Master-Branch in GitLab ein (Entwicklungsprozess gemäß GitHub Flow);
- SonarQube ist so konfiguriert, dass es den Code für das DPO-System termingerecht analysiert.
Unser Ziel: Automatische Code-Analyse in CI/CD-Prozessen von AVE implementieren.
Muss angepasst werden: Der Prozess der automatischen Überprüfung des Codes durch einen statischen Analysator bei jeder MergeRequest an den Hauptzweig.
Diese. Das Zielbild sieht wie folgt aus: Sobald der Entwickler Änderungen am Feature-Zweig hochlädt, startet eine automatische Prüfung auf neue Fehler im Code. Liegen keine Fehler vor, dürfen die Änderungen übernommen werden, andernfalls müssen die Fehler korrigiert werden. Bereits im Anfangsstadium konnten wir eine gewisse Anzahl von Fehlern im Code identifizieren. Das System verfügt über sehr flexible Einstellungen: Es kann so konfiguriert werden, dass es für bestimmte Aufgaben von Entwicklern, für jedes System und jeden Programmierstil funktioniert.
Konfigurieren von QualityGate in SonarQube
Die QualityGate-Analyse ist etwas, das wir in den Eingeweiden des Internets lesen. Anfangs haben wir einen anderen Ansatz gewählt, der komplexer und irgendwie nicht ganz korrekt war. Zuerst haben wir den Scan durch SonarQube zweimal durchgeführt: Wir haben den Feature-Branch und den Branch gescannt, in dem wir den Feature-Branch zusammenführen wollten, und dann haben wir die Anzahl der Fehler verglichen. Diese Methode war nicht stabil und lieferte nicht immer das richtige Ergebnis. Und dann haben wir erfahren, dass Sie SonarQube nicht zweimal ausführen müssen, sondern die Anzahl der gemachten Fehler begrenzen können (QualityGate) und nur den Zweig analysieren können, den Sie hochladen und vergleichen.
Im Moment verwenden wir noch eine eher primitive Codeprüfung. Es ist zu beachten, dass SonarQube mit einigen Programmiersprachen, einschließlich Delphi, nicht kompatibel ist. Derzeit analysieren wir für unser System nur PLSql-Code.
Es funktioniert so:
- Wir analysieren für unser Projekt ausschließlich PL/SQL-Code.
- QualityGate ist in SonarQube so konfiguriert, dass die Anzahl der Fehler mit dem Commit nicht ansteigt.
- Die Anzahl der Fehler beim ersten Durchlauf betrug 229. Wenn beim Festschreiben mehr Fehler auftreten, ist die Zusammenführung nicht zulässig.
- Darüber hinaus ist es vorbehaltlich der Fehlerbehebung möglich, QualityGate neu zu konfigurieren.
- Sie können auch neue Elemente zur Analyse hinzufügen, z. B. Codeabdeckung mit Tests usw.
Arbeitsschema:
In den Kommentaren des Skripts kann man erkennen, dass die Anzahl der Fehler im Feature-Zweig nicht zugenommen hat. Also ist alles in Ordnung.
Die Schaltfläche „Zusammenführen“ wird verfügbar.
In den Kommentaren des Skripts können Sie sehen, dass die Anzahl der Fehler im Feature-Branch größer geworden ist als zulässig. Also ist alles SCHLECHT.
Die Schaltfläche „Zusammenführen“ ist rot. Derzeit gibt es kein Verbot, Änderungen an fehlerhaftem Code hochzuladen, dies liegt jedoch im Ermessen des verantwortlichen Entwicklers. Zukünftig können Sie verhindern, dass solche Commits an den Hauptzweig vorgenommen werden.
Selbständiger Umgang mit Fehlern
Als nächstes müssen Sie alle vom System erkannten Fehler überprüfen, da SonarQube nach seinen strengen Standards analysiert. Was er für einen Fehler hält, ist in unserem Code möglicherweise kein Fehler. Bitte prüfen und beachten Sie daher, ob es sich wirklich um einen Fehler handelt oder ob eine Änderung unserer AGB nicht notwendig ist. Dadurch reduzieren wir die Fehleranzahl. Mit der Zeit wird das System lernen, diese Nuancen zu verstehen.
Wozu sind wir gekommen?
Unser Ziel war es herauszufinden, ob es in unserem Fall sinnvoll ist, die Codeüberprüfung auf Automatisierung zu übertragen. Und das Ergebnis entsprach den Erwartungen. Mit SonarQube können wir mit den Sprachen arbeiten, die wir benötigen, führen ziemlich kompetente Analysen durch und haben das Potenzial, aus Entwicklertipps zu lernen. Generell sind wir mit unseren ersten Erfahrungen mit SonarQube zufrieden und planen, uns in dieser Richtung weiterzuentwickeln. Wir gehen davon aus, dass wir in Zukunft mehr Zeit und Mühe bei der Codeüberprüfung einsparen und sie verbessern können, indem wir den menschlichen Faktor eliminieren. Vielleicht entdecken wir dabei die Mängel der Plattform oder stellen im Gegenteil noch einmal sicher, dass es sich um eine coole Sache mit großem Potenzial handelt.
In diesem Übersichtsartikel haben wir über unsere Bekanntschaft mit dem statischen Analysator SonarQube gesprochen. Wenn Sie Fragen haben, schreiben Sie bitte in die Kommentare. Wenn Sie sich für dieses Thema interessieren, werden wir in der neuen Veröffentlichung ausführlicher beschreiben, wie Sie alles richtig einrichten und Code schreiben, um eine solche Prüfung durchzuführen.
Autor des Textes:
Source: habr.com