Haluaisimme jakaa kokemuksemme SonarQube-koodin laadun jatkuvaan analysointiin ja mittaamiseen tarkoitetun alustan käyttöönotosta olemassa oleviin prosesseihin National Settlement Depositoryn DPO-järjestelmän (lisäys Alameda-säilytys- ja selvityslaskentajärjestelmään) kehittämiseksi.
National Settlement Depository (Moscow Exchange Group of Companies) on yksi tärkeimmistä rahoitusinfrastruktuuriyhtiöistä, joka säilyttää ja tallentaa venäläisten ja ulkomaisten liikkeeseenlaskijoiden arvopapereita yli 50 biljoonan ruplan arvosta. Järjestelmän suorittamien toimintojen kasvava määrä sekä toiminnallisuuden jatkuva lisääntyminen edellyttävät järjestelmien lähdekoodin korkean laadun ylläpitämistä. Yksi työkalu tämän tavoitteen saavuttamiseksi on SonarQube-staattinen analysaattori. Tässä artikkelissa kuvailemme onnistunutta kokemusta SonarQube-staattisen analysaattorin saumattomasti käyttöönotosta osastomme olemassa oleviin kehitysprosesseihin.
Lyhyesti osastosta
Osaamisemme sisältää seuraavat moduulit: maksut NSD-asiakkaille, sähköinen dokumenttien hallinta (EDF), kauppatietorekisterin viestien käsittely (pörssin ulkopuolisten tapahtumien rekisteröinti), sähköiset vuorovaikutuskanavat asiakkaiden ja NSD:n välillä ja paljon muuta. Yleensä toiminnan teknisellä puolella on paljon työtä. Työskentelemme hakemusten perusteella. Laskurien hakemukset käsittelevät analyytikot: he keräävät asiakkaiden vaatimuksia ja esittävät meille näkemyksensä siitä, miten sen tulisi sopia ohjelmaan. Lisäksi vakiomalli: koodin kehitys - testaus - koekäyttö - koodin toimitus tuotantopiiriin suoralle asiakkaalle.
Miksi SonarQube?
Tämä on osastomme ensimmäinen kokemus koodin laadunvalvontaalustan käyttöönotosta - aiemmin teimme sen manuaalisesti, vain koodin tarkistus. Mutta kasvava työmäärä vaatii tämän prosessin automatisoimista. Lisäksi tiimissä on myös kokemattomia työntekijöitä, jotka eivät ole täysin perehtyneet sisäiseen kehittämissääntelyyn ja tekevät enemmän virheitä. Koodin laadun valvomiseksi päätettiin ottaa käyttöön staattinen analysaattori. Koska SonarQubea on jo käytetty joissakin NSD-järjestelmissä, valinnan tekeminen ei kestänyt kauan. Aiemmin kollegat muilta divisioonalta analysoivat mikropalveluiden koodia Alameda-järjestelmässä (NSD:n oma talletus- ja selvityslaskentajärjestelmä), CFT:ssä (kirjanpidon, saldon, pakollisen ja sisäisen raportoinnin laatimisen tietojärjestelmä) joissakin muissa järjestelmät. Kokeilua varten päätimme aloittaa SonarQuben ilmaisella versiolla. Joten siirrytään tapauksiimme.
Toteutusprosessi
У нас есть:
- järjestelmän automaattinen kokoonpano TeamCityssä;
- määritä koodin lataaminen MergeRequestin kautta ominaisuushaarasta GitLabin päähaaraan (kehitysprosessi GitHub Flow'n mukaan);
- SonarQube on määritetty analysoimaan DPO-järjestelmän koodi aikataulussa.
Meidän maalimme: toteuttaa automaattinen koodianalyysi AVE:n CI/CD-prosesseissa.
Tarve mukauttaa: prosessi, jossa staattinen analysaattori tarkistaa koodin automaattisesti jokaisen päähaaran MergeRequest-pyynnön yhteydessä.
Nuo. kohdekuva on seuraavanlainen: heti kun kehittäjä lataa muutoksia ominaisuushaaran, alkaa automaattinen koodin uusien virheiden tarkistus. Jos virheitä ei ole, muutokset voidaan hyväksyä, muuten virheet on korjattava. Jo alkuvaiheessa pystyimme tunnistamaan tietyn määrän virheitä koodista. Järjestelmässä on erittäin joustavat asetukset: se voidaan konfiguroida siten, että se toimii tiettyihin kehittäjien tehtäviin, jokaiselle järjestelmälle ja ohjelmointityylille.
QualityGaten määrittäminen SonarQubessa
QualityGate-analyysi on asia, jota luemme Internetistä. Aluksi käytimme erilaista lähestymistapaa, monimutkaisempaa ja jotenkin epätäydellistä. Ensin suoritimme tarkistuksen SonarQuben kautta kahdesti: tarkistimme ominaisuushaaran ja haaran, johon aioimme yhdistää ominaisuushaaran, ja sitten vertailimme virheiden määrää. Tämä menetelmä ei ollut vakaa eikä aina antanut oikeaa tulosta. Ja sitten opimme, että sen sijaan, että suoritat SonarQubea kahdesti, voit asettaa rajan tehtyjen virheiden määrälle (QualityGate) ja analysoida vain lataamaasi haaraa ja vertailla.
Toistaiseksi käytämme edelleen melko alkeellista koodintarkistusta. On huomattava, että SonarQube ei ole yhteensopiva joidenkin ohjelmointikielten, mukaan lukien Delphi, kanssa. Tällä hetkellä analysoimme järjestelmässämme vain PLSql-koodia.
Se toimii näin:
- Analysoimme vain PL/SQL-koodia projektillemme.
- QualityGate on määritetty SonarQubessa siten, että virheiden määrä ei kasva vahvistuksen myötä.
- Virheiden määrä ensimmäisellä ajokerralla oli 229. Jos toimituksen aikana tulee enemmän virheitä, yhdistäminen ei ole sallittua.
- Lisäksi QualityGate voidaan määrittää uudelleen, mikäli virheet korjataan.
- Voit myös lisätä uusia kohteita analysoitavaksi, esimerkiksi koodin kattavuus testeillä jne.
Työsuunnitelma:
Skriptin kommenteista näet, että ominaisuushaaran virheiden määrä ei ole lisääntynyt. Kaikki on siis kunnossa.
Yhdistä-painike tulee saataville.
Skriptin kommenteista näkyy, että ominaisuushaaran virheiden määrä on noussut yli sallitun. Kaikki on siis PAHAA.
Yhdistä-painike on punainen. Tällä hetkellä ei ole kiellettyä ladata muutoksia virheelliseen koodiin, mutta tämä tapahtuu vastuullisen kehittäjän harkinnan mukaan. Jatkossa voit estää tällaisten sitoumusten tekemisen päähaaraan.
Itsehoito bugien kanssa
Seuraavaksi sinun on tarkistettava kaikki järjestelmän havaitsemat virheet, koska SonarQube analysoi tiukkojen standardiensa mukaisesti. Se, mitä hän pitää virheenä, ei välttämättä ole sitä koodissamme. Siksi sinun on tarkistettava ja huomioitava, onko tämä todella virhe, vai eikö ehdoissamme ole tarvetta muokata. Näin vähennämme virheiden määrää. Ajan myötä järjestelmä oppii ymmärtämään nämä vivahteet.
Mihin olemme tulleet
Tavoitteenamme oli ymmärtää, onko meidän tapauksessamme tarkoituksenmukaista siirtää koodin varmennus automaatioon. Ja tulos vastasi odotuksia. SonarQuben avulla voimme työskennellä tarvitsemillamme kielillä, tehdä melko päteviä analyyseja ja meillä on potentiaalia oppia kehittäjien vinkeistä. Yleisesti ottaen olemme tyytyväisiä ensimmäiseen kokemukseemme SonarQubesta ja aiomme kehittää edelleen tähän suuntaan. Odotamme, että voimme tulevaisuudessa säästää enemmän aikaa ja vaivaa koodin tarkistamisessa ja parantaa sitä eliminoimalla inhimillisen tekijän. Ehkä tässä prosessissa löydämme alustan puutteet, tai päinvastoin, varmistamme jälleen kerran, että tämä on siisti asia, jolla on paljon potentiaalia.
Tässä yleiskatsausartikkelissa puhuimme tutustumisestamme SonarQube-staattiseen analysaattoriin. Jos sinulla on kysyttävää, kirjoita kommentteihin. Jos olet kiinnostunut tästä aiheesta, kuvailemme uudessa julkaisussa yksityiskohtaisemmin, kuinka kaikki asetetaan oikein ja kirjoitetaan koodi tällaisen tarkistuksen suorittamiseksi.
Tekstin kirjoittaja:
Lähde: will.com