Vi vil gjerne dele vår erfaring med å implementere en plattform for kontinuerlig analyse og måling av kvaliteten på SonarQube-koden i de eksisterende prosessene for utvikling av DPO-systemet (et tillegg til Alameda-depot- og avregningsregnskapssystemet) til National Settlement Depository.
National Settlement Depository (Moscow Exchange Group of Companies) er et av de viktigste finansielle infrastrukturselskapene som lagrer og registrerer verdipapirer fra russiske og utenlandske utstedere verdt mer enn 50 billioner rubler. Det økende volumet av operasjoner som utføres av systemet, samt den kontinuerlige økningen i funksjonalitet, krever opprettholdelse av høy kvalitet på kildekoden til systemene. Et av verktøyene for å oppnå dette målet er SonarQube statiske analysator. I denne artikkelen beskriver vi den vellykkede opplevelsen av sømløst å implementere SonarQube statiske analysator i de eksisterende utviklingsprosessene til vår avdeling.
Kort om avdelingen
Vår kompetanse omfatter følgende moduler: betalinger til NSD-kunder, elektronisk dokumenthåndtering (EDF), behandling av meldinger fra transaksjonsregister (registrering av transaksjoner utenfor børs), elektroniske interaksjonskanaler mellom klienter og NSD, og mye mer. Generelt et stort lag med arbeid på den tekniske siden av driften. Vi jobber på bakgrunn av søknader. Søknader fra tellere behandles av analytikere: de samler inn kundekrav og presenterer oss deres visjon om hvordan det skal passe inn i programmet. Videre standardskjemaet: kodeutvikling - testing - prøvedrift - levering av koden til den produktive kretsen til den direkte kunden.
Hvorfor SonarQube?
Dette er den første erfaringen vår avdeling har med å implementere en plattform for kodekvalitetskontroll - tidligere gjorde vi det manuelt, kun kodegjennomgang. Men det økende arbeidsvolumet krever automatisering av denne prosessen. I tillegg er det også uerfarne ansatte i teamet som ikke er helt kjent med interne utviklingsregelverk og har en tendens til å gjøre flere feil. For å kontrollere kvaliteten på koden ble det besluttet å implementere en statisk analysator. Siden SonarQube allerede er brukt i noen NSD-systemer, tok det ikke lang tid å velge. Tidligere har kolleger fra andre divisjoner brukt det til å analysere koden til mikrotjenester i Alameda-systemet (NSDs eget depot- og avregningssystem), i CFT (informasjonssystem for regnskap, balanse, utarbeidelse av obligatorisk og intern rapportering), i noen andre systemer. For å eksperimentere bestemte vi oss for å starte med gratisversjonen av SonarQube. Så la oss gå videre til saken vår.
Implementeringsprosess
Vi har:
- automatisk montering av systemet i TeamCity;
- sette opp prosessen med å laste opp kode via MergeRequest fra en funksjonsgren til hovedgrenen i GitLab (utviklingsprosess i henhold til GitHub Flow);
- SonarQube konfigurert til å analysere koden for DPO-systemet etter planen.
Vårt mål: implementere automatisk kodeanalyse i CI/CD-prosesser til AVE.
Trenger å tilpasse: prosessen med å automatisk sjekke koden av en statisk analysator med hver MergeRequest til hovedgrenen.
De. målbildet er som følger: så snart utvikleren laster opp endringer til funksjonsgrenen, starter en automatisk sjekk for nye feil i koden. Hvis det ikke er noen feil, kan endringene godtas, ellers må feilene rettes. Allerede i det innledende stadiet klarte vi å identifisere et visst antall feil i koden. Systemet har svært fleksible innstillinger: det kan konfigureres på en slik måte at det fungerer for spesifikke oppgaver til utviklere, for hvert system og programmeringsstil.
Konfigurere QualityGate i SonarQube
QualityGate-analysen er en ting vi leser i innvollene på Internett. I utgangspunktet brukte vi en annen tilnærming, mer kompleks og på en eller annen måte ikke helt korrekt. Først kjørte vi skanningen gjennom SonarQube to ganger: vi skannet funksjonsgrenen og grenen der vi skulle slå sammen funksjonsgrenen, og så sammenlignet vi antall feil. Denne metoden var ikke stabil og ga ikke alltid riktig resultat. Og så lærte vi at i stedet for å kjøre SonarQube to ganger, kan du sette en grense på antall feil som gjøres (QualityGate) og kun analysere grenen du laster opp og sammenligner.
Foreløpig bruker vi fortsatt en ganske primitiv kodesjekk. Det skal bemerkes at SonarQube ikke er kompatibel med noen programmeringsspråk, inkludert Delphi. For øyeblikket, for systemet vårt, analyserer vi bare PLSql-kode.
Det fungerer slik:
- Vi analyserer kun PL/SQL-kode for prosjektet vårt.
- QualityGate er konfigurert i SonarQube slik at antall feil ikke øker med commit.
- Antall feil på den første kjøringen var 229. Hvis det er flere feil i løpet av commit, er sammenslåing ikke tillatt.
- Videre, med forbehold om feilretting, vil det være mulig å rekonfigurere QualityGate.
- Du kan også legge til nye elementer for analyse, for eksempel kodedekning med tester osv.
Arbeidsplan:
I kommentarene til skriptet kan du se at antall feil i funksjonsgrenen ikke har økt. Så alt er i orden.
Slå sammen-knappen blir tilgjengelig.
I kommentarene til skriptet kan du se at antall feil i funksjonsgrenen har blitt mer enn tillatt. Så alt er DÅRLIG.
Slå sammen-knappen er rød. For øyeblikket er det ikke noe forbud mot å laste opp endringer i feilkode, men dette gjøres etter den ansvarlige utviklerens skjønn. I fremtiden kan du forhindre at slike forpliktelser blir gjort til hovedavdelingen.
Selvhåndtering med feil
Deretter må du sjekke alle feilene som er oppdaget av systemet, fordi SonarQube analyserer i henhold til sine strenge standarder. Det han anser som en feil er kanskje ikke en i koden vår. Derfor må du sjekke og merke deg om dette virkelig er en feil, eller om det ikke er behov for å redigere i våre betingelser. Dermed reduserer vi antall feil. Over tid vil systemet lære å forstå disse nyansene.
Hva har vi kommet til
Målet vårt var å forstå om det er hensiktsmessig i vårt tilfelle å overføre kodeverifisering til automatisering. Og resultatet levde opp til forventningene. SonarQube lar oss jobbe med språkene vi trenger, gjør ganske kompetente analyser og har potensial til å lære av utviklertips. Generelt sett er vi fornøyd med vår første erfaring med SonarQube og planlegger å utvikle oss videre i denne retningen. Vi forventer at vi i fremtiden vil kunne spare mer tid og krefter på kodegjennomgang og gjøre det bedre ved å eliminere den menneskelige faktoren. Kanskje vil vi i prosessen oppdage manglene ved plattformen, eller tvert imot sørge for nok en gang at dette er en kul ting med stort potensial.
I denne oversiktsartikkelen snakket vi om vårt bekjentskap med SonarQube statiske analysator. Hvis du har spørsmål, vennligst skriv i kommentarfeltet. Hvis du er interessert i dette emnet, vil vi i den nye publikasjonen beskrive mer detaljert hvordan du setter opp alt riktig og skriver kode for å gjøre en slik sjekk.
Tekstforfatter:
Kilde: www.habr.com