We willen graag onze ervaring delen met het implementeren van een platform voor continue analyse en meting van de kwaliteit van de SonarQube-code in de bestaande processen voor het ontwikkelen van het DPO-systeem (een aanvulling op de Alameda depositary en clearing accounting system) van de National Settlement Depository.
De National Settlement Depository (Moscow Exchange Group of Companies) is een van de belangrijkste financiële infrastructuurbedrijven die effecten van Russische en buitenlandse emittenten met een waarde van meer dan 50 biljoen roebel opslaat en registreert. Het groeiende aantal bewerkingen dat door het systeem wordt uitgevoerd, evenals de voortdurende toename van de functionaliteit, vereisen dat de hoge kwaliteit van de broncode van de systemen behouden blijft. Een van de tools om dit doel te bereiken is de SonarQube static analyzer. In dit artikel beschrijven we de succesvolle ervaring van het naadloos implementeren van de SonarQube statische analyser in de bestaande ontwikkelprocessen van onze afdeling.
Even over de afdeling
Onze competentie omvat de volgende modules: betalingen aan NSD-klanten, elektronisch documentbeheer (EDF), verwerking van berichten in het handelsregister (registratie van transacties buiten de beurs), elektronische interactiekanalen tussen klanten en NSD, en nog veel meer. Over het algemeen een grote laag werk aan de technische kant van de operatie. Wij werken op basis van applicaties. Aanvragen van stemopnemers worden verwerkt door analisten: zij verzamelen wensen van de klant en presenteren ons hun visie op hoe het in het programma moet passen. Verder is het standaardschema: codeontwikkeling - testen - proefdraaien - levering van de code aan het productieve circuit aan de directe klant.
Waarom SonarQube?
Dit is de eerste ervaring van onze afdeling met het implementeren van een platform voor codekwaliteitscontrole - voorheen deden we dit handmatig, alleen codereview. Maar het groeiende werkvolume vereist automatisering van dit proces. Daarnaast zijn er ook onervaren medewerkers in het team die de interne ontwikkelregelgeving niet helemaal kennen en meer fouten maken. Om de kwaliteit van de code te controleren, werd besloten om een statische analysator te implementeren. Aangezien SonarQube al in sommige NSD-systemen is gebruikt, duurde het niet lang om te kiezen. Eerder gebruikten collega's van andere divisies het om de code van microservices te analyseren in het Alameda-systeem (NSD's eigen bewaar- en vereffeningsboekhoudsysteem), in het CFT (informatiesysteem voor boekhouding, saldo, voorbereiding van verplichte en interne rapportage), in sommige andere systemen. Om te experimenteren hebben we besloten om te beginnen met de gratis versie van SonarQube. Dus laten we verder gaan met onze zaak.
Implementatie proces
We hebben:
- automatische montage van het systeem in TeamCity;
- opzetten van het proces van het uploaden van code via MergeRequest van een feature branch naar de master branch in GitLab (ontwikkelingsproces volgens GitHub Flow);
- SonarQube is geconfigureerd om de code voor het DPO-systeem volgens schema te analyseren.
Ons doel: automatische code-analyse implementeren in CI/CD-processen van AVE.
Noodzaak om aan te passen: het proces van het automatisch controleren van de code door een statische analysator bij elke MergeRequest naar de hoofdtak.
Die. het doelbeeld is als volgt: zodra de ontwikkelaar wijzigingen in de functietak uploadt, start een automatische controle op nieuwe fouten in de code. Als er geen fouten zijn, mogen de wijzigingen worden geaccepteerd, anders moeten de fouten worden gecorrigeerd. Al in de beginfase hebben we een aantal fouten in de code kunnen identificeren. Het systeem heeft zeer flexibele instellingen: het kan zo worden geconfigureerd dat het werkt voor specifieke taken van ontwikkelaars, voor elk systeem en elke programmeerstijl.
QualityGate configureren in SonarQube
De QualityGate-analyse is iets dat we in de ingewanden van internet lezen. Aanvankelijk gebruikten we een andere benadering, complexer en in sommige opzichten niet helemaal correct. Eerst hebben we de scan twee keer door SonarQube laten lopen: we hebben de feature branch gescand en de branch waar we de feature branch gingen samenvoegen, en daarna hebben we het aantal fouten vergeleken. Deze methode was niet stabiel en gaf niet altijd het juiste resultaat. En toen leerden we dat in plaats van SonarQube twee keer uit te voeren, je een limiet kunt instellen op het aantal gemaakte fouten (QualityGate) en alleen de tak kunt analyseren die je uploadt en vergelijkt.
Voorlopig gebruiken we nog een nogal primitieve codecontrole. Opgemerkt moet worden dat SonarQube niet compatibel is met sommige programmeertalen, waaronder Delphi. Op dit moment analyseren we voor ons systeem alleen PLSql-code.
Het werkt als volgt:
- We analyseren alleen PL/SQL-code voor ons project.
- QualityGate is zo geconfigureerd in SonarQube dat het aantal fouten niet toeneemt met de commit.
- Het aantal fouten bij de eerste run was 229. Als er meer fouten zijn tijdens de commit, dan is merge niet toegestaan.
- Verder zal het, onder voorbehoud van correctie van fouten, mogelijk zijn om QualityGate opnieuw te configureren.
- U kunt ook nieuwe items toevoegen voor analyse, bijvoorbeeld codedekking met tests, enz.
Werkschema:
In de commentaren van het script kun je zien dat het aantal fouten in de feature branch niet is toegenomen. Dus alles is in orde.
De knop Samenvoegen wordt beschikbaar.
In de commentaren van het script kun je zien dat het aantal fouten in de feature branch meer dan toegestaan is geworden. Dus alles is SLECHT.
De knop Samenvoegen is rood. Op dit moment is er geen verbod op het uploaden van wijzigingen in foutieve code, maar dit wordt gedaan naar goeddunken van de verantwoordelijke ontwikkelaar. In de toekomst kun je voorkomen dat dergelijke commits naar de main branch worden gemaakt.
Zelf omgaan met bugs
Vervolgens moet u alle fouten controleren die door het systeem zijn gedetecteerd, omdat SonarQube analyseert volgens zijn strikte normen. Wat hij als een fout beschouwt, is misschien niet een fout in onze code. Daarom moet u controleren en noteren of dit echt een vergissing is, of dat het niet nodig is om onze voorwaarden aan te passen. Zo verminderen we het aantal fouten. Na verloop van tijd zal het systeem deze nuances leren begrijpen.
Waar zijn we op uitgekomen
Ons doel was om te begrijpen of het in ons geval zinvol is om codeverificatie over te hevelen naar automatisering. En het resultaat voldeed aan de verwachtingen. SonarQube stelt ons in staat om te werken met de talen die we nodig hebben, voert redelijk competente analyses uit en heeft het potentieel om te leren van ontwikkelaarstips. Over het algemeen zijn we tevreden met onze eerste ervaring met SonarQube en zijn we van plan ons in deze richting verder te ontwikkelen. We verwachten dat we in de toekomst meer tijd en moeite kunnen besparen op het beoordelen van code en deze kunnen verbeteren door de menselijke factor te elimineren. Misschien zullen we tijdens het proces de tekortkomingen van het platform ontdekken, of integendeel, we zullen er nogmaals voor zorgen dat dit een cool ding is met een groot potentieel.
In dit overzichtsartikel hebben we het gehad over onze kennismaking met de SonarQube static analyzer. Als je vragen hebt, schrijf dan in de comments. Als u geïnteresseerd bent in dit onderwerp, zullen we in de nieuwe publicatie in meer detail beschrijven hoe u alles correct instelt en code schrijft om een dergelijke controle uit te voeren.
Tekst auteur:
Bron: www.habr.com