Ons wil ons ervaring deel van die implementering van die SonarQube-platform vir deurlopende ontleding en meting van kodekwaliteit in die bestaande ontwikkelingsprosesse van die DPO-stelsel (toevoeging tot die Alameda-bewaarplek en verrekeningsrekeningstelsel) van die Nasionale Skikkingsbewaarplek.
Die National Settlement Depository (Moscow Exchange-groep van maatskappye) is een van die sleutelmaatskappye in die finansiële infrastruktuur, berging en verantwoording van sekuriteite van Russiese en buitelandse uitreikers ter waarde van meer as 50 triljoen roebels. Die groeiende volume bedrywighede wat deur die stelsel uitgevoer word, sowel as die voortdurende uitbreiding van funksionaliteit, vereis die handhawing van hoë kwaliteit bronkode van die stelsels. Een instrument om hierdie doel te bereik is die SonarQube statiese ontleder. In hierdie artikel sal ons die suksesvolle ervaring beskryf om die SonarQube statiese ontleder naatloos in die bestaande ontwikkelingsprosesse van ons departement te implementeer.
Kortliks oor die departement
Ons bevoegdheid sluit die volgende modules in: betalings aan NSD-kliënte, elektroniese dokumentbestuur (EDF), verwerking van handelsbewaarplekboodskappe (registrasie van oor-die-toonbank-transaksies), kanale van elektroniese interaksie tussen kliënte en NSD, en nog baie meer. Oor die algemeen is daar baie werk wat gedoen moet word aan die tegniese kant van operasionele aktiwiteite. Ons werk op grond van versoeke. Aansoeke van bedryfsbeamptes word deur ontleders verwerk: hulle versamel die kliënt se vereistes en bied aan ons hul visie van hoe dit by die program moet inpas. Volgende is die standaardskema: kode-ontwikkeling - toetsing - proefwerking - aflewering van die kode na die produksiekring aan die direkte kliënt.
Hoekom SonarQube?
Dit is die eerste ondervinding van ons departement met die implementering van 'n platform vir kodekwaliteitbeheer - voorheen het ons dit met die hand gedoen en slegs kodehersiening uitgevoer. Maar die groeiende volume werk vereis outomatisering van hierdie proses. Daarbenewens sluit die span ook onervare werknemers in wat nie heeltemal vertroud is met interne ontwikkelingsregulasies nie en geneig is om meer foute te maak. Om die kwaliteit van die kode te beheer, is besluit om 'n statiese ontleder te implementeer. Aangesien SonarQube reeds in sommige NSD-stelsels gebruik is, was daar geen lang keuse nie. Voorheen het kollegas van ander departemente dit gebruik om die kode van mikrodienste in die Alameda-stelsel (NSD se eie deposito- en verrekeningsrekeningstelsel), in CFT ('n inligtingstelsel vir die handhawing van rekeningkunde, balansstate, die voorbereiding van verpligte en interne verslagdoening), in sommige ander stelsels. Vir eksperimente het ons besluit om met die gratis weergawe van SonarQube te begin. Kom ons gaan dus oor na ons saak.
Implementeringsproses
Ons het:
- outomatiese stelselsamestelling in TeamCity;
- die proses van die oplaai van kode via MergeRequest vanaf die kenmerktak na die meestertak in GitLab is gekonfigureer (ontwikkelingsproses volgens GitHub Flow);
- SonarQube, gekonfigureer om kode vir die DPO-stelsel op 'n skedule te ontleed.
Ons mikpunt: implementeer outomatiese kode-analise in CI/CD-prosesse van DPO.
Moet konfigureer: die proses om kode outomaties na te gaan met 'n statiese ontleder met elke MergeRequest na die hooftak.
Dié. Die teikenprentjie is soos volg: sodra die ontwikkelaar veranderinge na die kenmerktak oplaai, word 'n outomatiese kontrolering vir nuwe foute in die kode geloods. As daar geen foute is nie, word die veranderinge toegelaat om aanvaar te word, anders sal die foute reggestel moet word. Reeds in die aanvanklike stadium kon ons 'n sekere aantal foute in die kode identifiseer. Die stelsel het baie buigsame instellings: dit kan so gekonfigureer word dat dit werk vir die spesifieke take van ontwikkelaars, vir elke stelsel en programmeringstyl.
Stel QualityGate in SonarQube op
QualityGate-analise is iets wat ons in die dieptes van die internet lees. Aanvanklik het ons 'n ander benadering gebruik, meer kompleks en in sekere opsigte nie heeltemal korrek nie. Eerstens het ons die skandering twee keer deur SonarQube uitgevoer: ons het die kenmerktak en die tak waar ons die kenmerktak gaan saamvoeg, geskandeer en dan die aantal foute vergelyk. Hierdie metode was nie stabiel nie en het nie altyd die korrekte resultaat opgelewer nie. En toe vind ons uit dat in plaas daarvan om SonarQube twee keer te laat loop, ons 'n limiet kan stel op die aantal foute wat gemaak word (QualityGate) en net die tak wat jy oplaai en vergelyk kan ontleed.
Vir nou gebruik ons steeds 'n taamlik primitiewe kode-oorsig. Dit is opmerklik dat SonarQube nie versoenbaar is met sommige programmeertale, insluitend Delphi nie. Op die oomblik ontleed ons slegs PLSql-kode vir ons stelsel.
Dit werk so:
- Ons ontleed slegs PL/SQL-kode vir ons projek.
- SonarQube het QualityGate so opgestel dat die aantal foute nie met 'n commit toeneem nie.
- Die aantal foute by die eerste bekendstelling was 229. As daar meer foute tydens 'n commit is, word samesmelting nie toegelaat nie.
- Verder, as foute reggestel word, sal dit moontlik wees om QualityGate te herkonfigureer.
- Jy kan ook nuwe punte vir ontleding byvoeg, byvoorbeeld kodedekking met toetse, ens.
Werkskema:
Die opmerkings van die skrif toon dat die aantal foute in die kenmerktak nie toegeneem het nie. So alles is reg.
Die Merge-knoppie word beskikbaar.
In die opmerkings van die skrif kan jy sien dat die aantal foute in die kenmerktak meer as aanvaarbaar geword het. Alles is dus SLEG.
Die Merge-knoppie is rooi. Op die oomblik is daar geen verbod op die oplaai van veranderinge gebaseer op foutiewe kode nie, maar dit word gedoen volgens die diskresie van die verantwoordelike ontwikkelaar. In die toekoms kan jy verhoed dat sulke verbintenisse by die hooftak gevoeg word.
Onafhanklike werk op foute
Vervolgens moet u alle foute wat deur die stelsel opgespoor word, nagaan, want SonarQube ontleed volgens sy streng standaarde. Wat hy as 'n fout beskou, is dalk nie eintlik een in ons kode nie. Daarom moet u nagaan en let op of dit werklik 'n fout is, en of dit nie nodig is om in ons voorwaardes te wysig nie. Op hierdie manier verminder ons die aantal foute. Met verloop van tyd sal die stelsel leer om hierdie nuanses te verstaan.
Waartoe het ons gekom
Ons doel was om te verstaan of dit in ons geval raadsaam sou wees om kodehersiening na outomatisering oor te dra. En die resultaat het aan die verwagtinge voldoen. SonarQube stel ons in staat om te werk met die tale wat ons nodig het, doen redelik bekwame ontleding en het die potensiaal om uit ontwikkelaarwenke te leer. Oor die algemeen is ons tevrede met ons eerste ervaring met SonarQube en beplan om verder in hierdie rigting te ontwikkel. Ons verwag dat ons in die toekoms meer tyd en moeite sal kan bespaar op kodehersiening en dit beter sal kan maak deur die menslike faktor uit te skakel. Miskien sal ons in die proses die tekortkominge van die platform ontdek of, omgekeerd, sal ons weer oortuig wees dat dit 'n gawe ding met groot potensiaal is.
In hierdie oorsigartikel het ons gepraat oor ons kennismaking met die SonarQube statiese ontleder. As jy vrae het, skryf asseblief in die kommentaar. As jy belangstel in hierdie onderwerp, sal ons in 'n nuwe publikasie in meer besonderhede beskryf hoe om alles korrek op te stel en kode te skryf om so 'n kontrole te doen.
Teks skrywer:
Bron: will.com