Szeretnénk megosztani tapasztalatainkat a SonarQube kódminőség folyamatos elemzésére és mérésére szolgáló platform bevezetésével kapcsolatban, amelyet a DPO rendszer fejlesztési folyamataiba integráltunk (kiegészítés az "Alameda" letéti-kollégiumi nyilvántartási rendszerhez) a Nemzeti elszámolóházban.
A Nemzeti elszámolóház (a Moszkvai Tőzsde csoportja) a pénzügyi infrastruktúra egyik kulcsszereplője, amely több mint 50 ezer milliárd rubel értékű orosz és külföldi kibocsátók értékpapírjait tárolja és számolja el. A rendszeren végzett tranzakciók növekvő volumene, valamint a folyamatos funkcióbővülés megköveteli a rendszerek forráskódjának magas minőségének fenntartását. Ennek a célnak az elérésére az egyik eszköz a SonarQube statikus elemző. Ebben a cikkben bemutatjuk a SonarQube statikus elemző zökkenőmentes bevezetésének sikeres tapasztalatait a részlegünk fejlesztési folyamataiba.
Röviden a részlegről
Kompetenciánkba tartozik a következő modulok: kifizetések az NRD ügyfeleinek, elektronikus dokumentumforgalom (EDO), tőzsdei letéti rendszer üzeneteinek feldolgozása (tőzsdén kívüli ügyletek nyilvántartása), elektronikus kapcsolattartási csatornák az NRD ügyfelei és a vállalat között, és sok más. Összességében nagy területet képvisel a működés technikai oldalával kapcsolatos munka. Kérelem alapján dolgozunk. Az operátorok kéréseit az elemzők dolgozzák fel: ők összegyűjtik az ügyfél követelményeit, és bemutatják nekünk, hogy szerintük hogyan kellene a programba integrálni. A szokásos forgatókönyv: kódfejlesztés – tesztelés – próbaüzem – kód átadása a végfelhasználónak.
Miért éppen a SonarQube?
Ez az első tapasztalatunk a kódminőség-ellenőrző platform bevezetésében – korábban manuálisan végeztük ezt, csak kódellenőrzéseket végeztünk. De a növekvő munkamennyiség automatizálást igényel. Ezen kívül a csapatban vannak tapasztalatlan munkatársak is, akik nem ismerik teljesen a fejlesztési belső szabályokat, és hajlamosak több hibát elkövetni. A kódminőség ellenőrzésére úgy döntöttünk, hogy statikus elemzőt vezetünk be. Mivel a SonarQube már használták egyes NRD rendszerekben, így nem kellett sokat választanunk. Korábban a más osztályokból származó kollégák a mikroservice kódját elemezték a “Alameda” rendszerben (NRD sajátlet érdem-számláló-kliens rendszere), a CFT-ben (számviteli rendszer a könyvelés, egyensúly, kötelező és belső jelentések előkészítése szempontjából), és néhány más rendszerben. Kísérletekhez úgy döntöttünk, hogy a SonarQube ingyenes verziójával kezdünk. Tehát lépjünk tovább az esettanulmányunkra.
A bevezetési folyamat
Van egy:
- automatikus rendszerépítés a TeamCity-ben;
- be van állítva a kód feltöltése MergeRequest-en keresztül a feature-ágból a master-ágba a GitLab-ban (fejlesztési folyamat a GitHub Flow szerint);
- SonarQube, amely a DPO rendszer kódanalízisére van beállítva ütemezés szerint.
Célunk: bevezetni a kód automatikus ellenőrzését a DPO CI/CD folyamatokban.
Be kell állítani: a kód automatikus ellenőrzési folyamatát statikus elemzővel minden MergeRequest esetén a fő ágba.
Tehát a célszerű helyzet a következő: amint a fejlesztő feltölti a módosításokat a feature-ágba, elindul az automatikus ellenőrzés az új hibákra a kódban. Ha nincsenek hibák, akkor engedélyezhetők a módosítások, ellenkező esetben javítani kell a hibákat. Már az első lépésben képesek voltunk meghatározott számú hibát felfedezni a kódban. A rendszer nagyon rugalmas beállításokkal rendelkezik: úgy konfigurálható, hogy a fejlesztők konkrét feladataihoz, minden rendszerhez és programozási stílushoz illeszkedjen.
A QualityGate beállítása a SonarQube-ban
A QualityGate elemzés az a téma, amelyet az internet mélyén találtunk. Eleinte egy másik, bonyolultabb és bizonyos szempontból nem teljesen helyes megközelítést használtunk. Először kétszer futtattuk a szkennelést a SonarQube-on: beolvastuk a funkcióágat és azt az ágat, ahová a funkcióágat akartuk integrálni, majd összehasonlítottuk a hibák számát. Ez a módszer nem volt stabil, és nem mindig adott helyes eredményt. Aztán megtudtuk, hogy a dupla SonarQube végrehajtás helyett beállíthatunk egy határt az elfogadott hibák számára (QualityGate), és csak azt az ágat elemezhetjük, amelyet feltöltünk és összehasonlítunk.
Jelenleg még mindig viszonylag primitív kódellenőrzést alkalmazunk. Meg kell jegyezni, hogy a SonarQube nem kompatibilis bizonyos programozási nyelvekkel, beleértve a Delphi-t is. Jelenleg csak a PLSQL kódot elemezzük a rendszerünkben.
Ez így működik:
- A projektünk számára kizárólag PL/SQL kódot elemezünk.
- A SonarQube QualityGate beállítva úgy, hogy a hibák száma ne növekedjen a commit során.
- Az első futtatás során 229 hibát találtunk. Ha commit során a hibák száma nő, akkor a merge nem engedélyezett.
- Hibák javításának feltétele mellett a QualityGate újra beállítható.
- Újabb elemzési elemeket is hozzáadhatunk, például a tesztlefedettséget stb.
Működési séma:
A script futásának megjegyzéseiből látható, hogy a hibák száma a funkcióágban nem nőtt. Tehát minden rendben van.
A Merge gomb elérhetővé válik.
A script futásának megjegyzéseiből látható, hogy a hibák száma a funkcióágban meghaladta a megengedett értéket. Tehát mindenROSSZ.
A Merge gomb piros. Jelenleg nincs tilalom arra, hogy a hibás kód módosításait feltöltsük, de ezt a felelős fejlesztő megítélése szerint kell tenni. Jövőben megtiltható a hasonló commitok végrehajtása az alapágban.
Hibák önálló megoldása
Ezután szükséges ellenőrizni az összes, a rendszer által észlelt hibát, mivel a SonarQube szigorú szabványok szerint végez elemzést. Amit ő hibának tart, az valójában nem biztos, hogy hibás a kódunkban. Ezért ellenőrizni kell, és meg kell jelölni, hogy ez valóban hiba-e, vagy olyan dolog, amire nincs szükség a környezetünkben. Ezzel csökkentjük a hibák számát. Idővel a rendszer megtanulja, hogyan érti ezeket a finomságokat.
Hova jutottunk?
Célunk az volt, hogy megértsük, célszerű-e az automatizált kódellenőrzést a mi esetünkben bevezetni. Az eredmény meghaladta a várakozásainkat. A SonarQube lehetővé teszi számunkra, hogy a számunkra szükséges nyelvekkel dolgozzunk, meglehetősen pontos elemzést végez, és képes tanulni a fejlesztők útmutatásaiból. Összességében elégedettek vagyunk az első SonarQube-élményünkkel, és továbbra is fejlődni szeretnénk ezen a téren. Arra számítunk, hogy a jövőben még több időt és energiát tudunk megtakarítani a kódellenőrzés során, és javítani tudjuk annak minőségét, kiküszöbölve az emberi tényezőt. Lehetséges, hogy a folyamat során felfedezünk a platform hiányosságait, vagy éppen ellenkezőleg, újra megerősítjük, hogy ez egy nagyszerű dolog, nagy potenciállal.
Ebben az áttekintő cikkben beszámoltunk a SonarQube statikus elemzővel való ismerkedésünkről. Ha kérdései vannak, kérjük, írja meg kommentben. Ha érdekli ez a téma, egy új bejegyzésben részletesebben leírjuk, hogyan állíthatjuk be helyesen mindezt, és hogyan írhatunk kódot, hogy ilyen ellenőrzést végezhessünk.
A szöveg szerzője:
Forrás: habr.com
