Vi ønsker at dele erfaringerne fra implementeringen af SonarQube-platformen til løbende analyse og måling af kodekvalitet i de eksisterende udviklingsprocesser for DPO-systemet (tilføjelse til det depo- og clearingregnskabssystem "Alameda") Nationalt beregningsdepot.
Det Nationale Beregningsdepot (gruppen af virksomheder "Moskva Børsen") er en af de centrale aktører i den finansielle infrastruktur og opbevarer og registrerer værdipapirer fra russiske og udenlandske udstedere for mere end 50 billioner rubler. Den stigende mængde operationer, som systemet udfører, samt den kontinuerlige udvidelse af funktionaliteten kræver opretholdelse af høj kvalitet i kildeteksten for systemerne. Et af de værktøjer, der bruges til at opnå dette mål, er den statiske analyseværktøj SonarQube. I denne artikel vil vi beskrive vores succesfulde erfaring med problemfri implementering af SonarQube i vores udviklingsafdelings eksisterende processer.
Kort om afdelingen
Vores kompetenceområder inkluderer følgende moduler: udbetalinger til kunderne i NRD, elektronisk dokumenthåndtering (EDO), behandling af meddelelser fra handelsdepotet (registrering af over-the-counter handler), elektroniske kommunikationskanaler mellem kunderne og NRD samt meget mere. Samlet set er der et stort arbejde med den tekniske side af den operationelle aktivitet. Vi arbejder på baggrund af anmodninger. Anmodninger fra operatører behandles af analytikere: de indsamler kundens krav og præsenterer os for deres syn på, hvordan dette skal indgå i programmet. Herefter følger den standardiserede proces: kodeudvikling – testning – prøvebetræning – levering af koden til det produktive miljø til den direkte kunde.
Hvorfor netop SonarQube?
Dette er den første erfaring for vores afdeling med implementeringen af en platform til kvalitetskontrol af kode – tidligere har vi gjort det manuelt ved kun at udføre code review. Men det voksende arbejdsvolumen kræver automatisering af denne proces. Desuden er der uerfarne medarbejdere i teamet, som ikke er helt bekendt med de interne udviklingsregler og derfor har en tendens til at lave flere fejl. Det blev besluttet at implementere en statisk analyzer til kvalitetskontrol af koden. Da SonarQube allerede blev brugt i nogle NRD-systemer, var der ikke meget at overveje. Tidligere har kolleger fra andre afdelinger analyseret koden fra mikrotjenester i systemet "Alemada" (et eget depot- og clearingregnskabssystem for NRD), i CFT (et informationssystem til bogføring, balance og udarbejdelse af obligatorisk og intern rapportering) samt i nogle andre systemer. Til eksperimenterne besluttede vi at starte med den gratis version af SonarQube. Lad os gå videre til vores case.
Implementeringsprocessen
Vi har:
- automatisk byggesystem i TeamCity;
- konfigureret processen til at uploade koden via MergeRequest fra feature-grenen til master-grenen i GitLab (udviklingsprocessen i henhold til GitHub Flow);
- SonarQube, konfigureret til at analysere koden for DPO-systemet efter en tidsplan.
Vores mål: at implementere automatisk kodeanalyse i CI/CD processerne for DPO.
Det er nødvendigt at konfigurere: processen for automatisk kontrol af koden med den statiske analyzer ved hver MergeRequest til hovedgrenen.
Det vil sige, det ønskede scenario er som følger: så snart udvikleren uploader ændringer til feature-grenen, starter den automatiske kontrol for at finde nye fejl i koden. Hvis der ikke er fejl, er ændringerne tilladt, ellers skal der rettes fejl. Allerede i den tidlige fase kunne vi identificere et bestemt antal fejl i koden. Systemet har meget fleksible indstillinger: det kan konfigureres således, at det fungerer til specifikke opgaver for udviklerne, til hvert system og programmeringsstil.
Konfiguration af QualityGate i SonarQube
QualityGate-analyse er noget, vi har lært om i internettets dybder. Oprindeligt brugte vi en anden tilgang, en der var mere kompleks og på nogle måder ikke helt korrekt. Først kørte vi scanningen gennem SonarQube to gange: scannede feature-grenen og grenen, hvortil vi ville fusionere feature-grenen, og sammenlignede derefter antallet af fejl. Denne metode var ikke stabil og gav ikke altid det rigtige resultat. Så fandt vi ud af, at i stedet for at køre SonarQube to gange, kunne vi sætte en grænse for antallet af tilladte fejl (QualityGate) og kun analysere den gren, vi uploader og sammenligner.
Indtil nu bruger vi stadig en ret primitiv kodekontrol. Det skal bemærkes, at SonarQube ikke er kompatibel med nogle programmeringssprog, herunder Delphi. I øjeblikket analyserer vi kun PLSql-kode til vores system.
Sådan fungerer det:
- Vi analyserer kun PL/SQL-koden for vores projekt.
- I SonarQube er QualityGate indstillet således, at antallet af fejl ikke stiger med et commit.
- Antallet af fejl ved første kørsel var 229. Hvis antallet af fejl under commit stiger, er fusionsmuligheden ikke tilladt.
- Dernæst, hvis fejlene rettes, kan QualityGate omkonfigureres.
- Det er også muligt at tilføje nye punkter til analysen, for eksempel kodeafprøvning og så videre.
Arbejdsschema:
I kommentarerne til scriptets kørsel kan man se, at antallet af fejl i feature-grenen ikke er steget. Det betyder alt er OK.
Fusionsknappen bliver tilgængelig.
I kommentarerne til scriptets kørsel kan man se, at antallet af fejl i feature-grenen er blevet større end tilladt. Det betyder alt er DÅRLIGT.
Fusionsknappen er rød. I øjeblikket er der ingen forbud mod at uploade ændringer med fejl i koden, men det skal ske efter ansvarlig udviklers skøn. Fremover kan det være muligt at forbyde sådanne commits i hovedgrenen.
Selvstændigt arbejde med fejlene
Det er nødvendigt at tjekke alle fejl, systemet har identificeret, fordi SonarQube analyserer efter sine strenge standarder. Hvad den betragter som en fejl, kan i vores kode muligvis ikke være en reel fejl. Derfor skal det tjekkes og noteres, om det virkelig er en fejl, eller om der i vores situation ikke er behov for at rette det. På denne måde reducerer vi antal fejl. Over tid vil systemet lære at forstå disse nuancer.
Hvor endte vi hen?
Vores mål var at forstå, om det var fornuftigt at automatisere kodekontrol i vores tilfælde. Og resultatet levede op til forventningerne. SonarQube gør det muligt for os at arbejde med de sprog, vi har brug for, udfører en ret grundig analyse og har potentiale til at lære af udviklernes input. Generelt er vi tilfredse med vores første erfaring med SonarQube og planlægger at udvikle os yderligere i denne retning. Vi forventer, at vi i fremtiden kan spare mere tid og kræfter på kodekontrol og gøre den mere kvalitetsfyldt ved at eliminere den menneskelige faktor. Måske finder vi i processen nogle ulemper ved platformen, eller omvendt, bekræfter vi endnu engang, at det er en fantastisk ting med stort potentiale.
I denne oversigtsartikel har vi delt vores første møde med den statiske analyser SonarQube. Hvis du har spørgsmål, skal du endelig skrive dem i kommentarerne. Hvis du er interesseret i emnet, vil vi i en ny publikation detaljeret beskrive, hvordan man korrekt sætter alt op og skriver kode for at udføre en sådan kontrol.
Forfatteren af teksten:
Kilde: habr.com
