Vi vil gerne dele vores erfaring med at implementere en platform til kontinuerlig analyse og måling af kvaliteten af SonarQube-koden i de eksisterende processer til udvikling af DPO-systemet (en tilføjelse til Alamedas depositar- og clearingregnskabssystem) i National Settlement Depository.
National Settlement Depository (Moscow Exchange Group of Companies) er en af de vigtigste finansielle infrastrukturvirksomheder, der opbevarer og registrerer værdipapirer fra russiske og udenlandske udstedere til en værdi af mere end 50 billioner rubler. Den voksende mængde operationer, der udføres af systemet, samt den kontinuerlige stigning i funktionalitet, kræver opretholdelse af den høje kvalitet af systemernes kildekode. Et af værktøjerne til at nå dette mål er SonarQube statiske analysator. I denne artikel beskriver vi den succesrige oplevelse med problemfri implementering af SonarQube statiske analysator i de eksisterende udviklingsprocesser i vores afdeling.
Kort om afdelingen
Vores kompetence omfatter følgende moduler: betalinger til NSD-kunder, elektronisk dokumenthåndtering (EDF), behandling af transaktionsregistre-meddelelser (registrering af transaktioner uden for børsen), elektroniske interaktionskanaler mellem kunder og NSD og meget mere. Generelt et stort lag arbejde på den tekniske side af driften. Vi arbejder ud fra ansøgninger. Ansøgninger fra stemmetællere behandles af analytikere: de indsamler kundekrav og præsenterer os deres vision om, hvordan det skal passe ind i programmet. Yderligere standardskemaet: kodeudvikling - test - prøvedrift - levering af koden til det produktive kredsløb til den direkte kunde.
Hvorfor SonarQube?
Dette er vores afdelings første erfaring med at implementere en platform for kodekvalitetskontrol - tidligere gjorde vi det manuelt, kun kodegennemgang. Men den voksende mængde arbejde kræver automatisering af denne proces. Derudover er der også uerfarne medarbejdere i teamet, som ikke er helt fortrolige med interne udviklingsregler og har en tendens til at lave flere fejl. For at kontrollere kvaliteten af koden blev det besluttet at implementere en statisk analysator. Da SonarQube allerede er blevet brugt i nogle NSD-systemer, tog det ikke lang tid at vælge. Tidligere brugte kolleger fra andre afdelinger det til at analysere koden for mikrotjenester i Alameda-systemet (NSD's eget depot- og clearingregnskabssystem), i CFT (informationssystem til regnskab, balance, udarbejdelse af obligatorisk og intern rapportering), i nogle andre systemer. For at eksperimentere besluttede vi at starte med den gratis version af SonarQube. Så lad os gå videre til vores sag.
Implementeringsproces
Vi har:
- automatisk samling af systemet i TeamCity;
- opsætte processen med at uploade kode via MergeRequest fra en funktionsgren til mastergrenen i GitLab (udviklingsproces i henhold til GitHub Flow);
- SonarQube konfigureret til at analysere koden for DPO-systemet efter tidsplan.
Vores mål: implementere automatisk kodeanalyse i CI/CD-processer i AVE.
Skal tilpasses: processen med automatisk kontrol af koden af en statisk analysator med hver MergeRequest til hovedgrenen.
De der. målbilledet er som følger: så snart udvikleren uploader ændringer til funktionsgrenen, starter en automatisk kontrol for nye fejl i koden. Hvis der ikke er nogen fejl, så tillades ændringerne at blive accepteret, ellers skal fejlene rettes. Allerede i den indledende fase var vi i stand til at identificere et vist antal fejl i koden. Systemet har meget fleksible indstillinger: det kan konfigureres på en sådan måde, at det fungerer til specifikke opgaver for udviklere, for hvert system og programmeringsstil.
Konfiguration af QualityGate i SonarQube
QualityGate-analysen er en ting, som vi læser i internettets indvolde. I starten brugte vi en anden tilgang, mere kompleks og på nogle måder ikke helt korrekt. Først kørte vi scanningen gennem SonarQube to gange: vi scannede feature-grenen og grenen, hvor vi skulle flette feature-grenen, og derefter sammenlignede vi antallet af fejl. Denne metode var ikke stabil og gav ikke altid det korrekte resultat. Og så lærte vi, at i stedet for at køre SonarQube to gange, kan du sætte en grænse for antallet af fejl, der laves (QualityGate) og kun analysere den gren, du uploader og sammenligner.
Indtil videre bruger vi stadig et ret primitivt kodetjek. Det skal bemærkes, at SonarQube ikke er kompatibel med nogle programmeringssprog, inklusive Delphi. I øjeblikket analyserer vi kun PLSql-kode for vores system.
Det fungerer sådan her:
- Vi analyserer kun PL/SQL-kode for vores projekt.
- QualityGate er konfigureret i SonarQube, så antallet af fejl ikke stiger med commit.
- Antallet af fejl ved første kørsel var 229. Hvis der er flere fejl under commit, så er merge ikke tilladt.
- Yderligere, med forbehold for rettelse af fejl, vil det være muligt at omkonfigurere QualityGate.
- Du kan også tilføje nye elementer til analyse, for eksempel kodedækning med test mv.
Arbejdsplan:
I kommentarerne til scriptet kan du se, at antallet af fejl i featuregrenen ikke er steget. Så alt er i orden.
Knappen Flet bliver tilgængelig.
I kommentarerne til scriptet kan du se, at antallet af fejl i feature-grenen er blevet mere end tilladt. Så alt er DÅRLIGT.
Flet-knappen er rød. På nuværende tidspunkt er der intet forbud mod at uploade ændringer til fejlagtig kode, men dette sker efter den ansvarlige udviklers skøn. I fremtiden kan du forhindre sådanne commits i at blive foretaget til hovedgrenen.
Uafhængigt arbejde med fejlene
Dernæst skal du kontrollere alle de fejl, der er opdaget af systemet, fordi SonarQube analyserer i henhold til dets strenge standarder. Det, han betragter som en fejl, er muligvis ikke en i vores kode. Derfor skal du tjekke og notere, om dette virkelig er en fejl, eller om der ikke er behov for at redigere i vores betingelser. Dermed reducerer vi antallet af fejl. Med tiden vil systemet lære at forstå disse nuancer.
Hvad er vi kommet til
Vores mål var at forstå, om det i vores tilfælde er hensigtsmæssigt at overføre kodeverifikation til automatisering. Og resultatet levede op til forventningerne. SonarQube giver os mulighed for at arbejde med de sprog, vi har brug for, laver ret kompetente analyser og har potentialet til at lære af udviklertips. Generelt er vi glade for vores første erfaring med SonarQube og planlægger at udvikle os yderligere i denne retning. Vi forventer, at vi i fremtiden vil kunne spare mere tid og kræfter på kodegennemgang og gøre det bedre ved at eliminere den menneskelige faktor. Måske opdager vi i processen platformens mangler, eller tværtimod sørger vi igen for, at det er en fed ting med et stort potentiale.
I denne oversigtsartikel talte vi om vores bekendtskab med SonarQube statiske analysator. Hvis du har spørgsmål, så skriv venligst i kommentarerne. Hvis du er interesseret i dette emne, vil vi i den nye publikation beskrive mere detaljeret, hvordan du opsætter alt korrekt og skriver kode for at udføre en sådan kontrol.
Tekstforfatter:
Kilde: www.habr.com