Ne dëshirojmë të ndajmë përvojën tonë të zbatimit të një platforme për analiza dhe matje të vazhdueshme të cilësisë së kodit SonarQube në proceset ekzistuese për zhvillimin e sistemit DPO (një shtesë në sistemin e depozitimit dhe kontabilitetit të kleringut Alameda) të Depozitës Kombëtare të Shlyerjes.
Depozita Kombëtare e Shlyerjeve (Grupi i Kompanive të Shkëmbimit të Moskës) është një nga kompanitë kryesore të infrastrukturës financiare që ruan dhe regjistron letra me vlerë të emetuesve rusë dhe të huaj me vlerë më shumë se 50 trilion rubla. Vëllimi në rritje i operacioneve të kryera nga sistemi, si dhe rritja e vazhdueshme e funksionalitetit, kërkojnë ruajtjen e cilësisë së lartë të kodit burimor të sistemeve. Një nga mjetet për të arritur këtë qëllim është analizuesi statik SonarQube. Në këtë artikull, ne përshkruajmë përvojën e suksesshme të zbatimit të pandërprerë të analizuesit statik SonarQube në proceset ekzistuese të zhvillimit të departamentit tonë.
Shkurtimisht për departamentin
Kompetenca jonë përfshin modulet e mëposhtme: pagesat për klientët NSD, menaxhimin e dokumenteve elektronike (EDF), përpunimin e mesazheve të depove tregtare (regjistrimi i transaksioneve jashtë këmbimit), kanalet e ndërveprimit elektronik midis klientëve dhe NSD, dhe shumë më tepër. Në përgjithësi, një shtresë e madhe e punës në anën teknike të operacioneve. Ne punojmë në bazë të aplikacioneve. Aplikimet e treguesve përpunohen nga analistët: ata mbledhin kërkesat e klientëve dhe na paraqesin vizionin e tyre se si duhet të përshtatet në program. Më tej, skema standarde: zhvillimi i kodit - testimi - funksionimi i provës - dërgimi i kodit në qarkun prodhues tek klienti i drejtpërdrejtë.
Pse SonarQube?
Kjo është përvoja e parë e departamentit tonë në zbatimin e një platforme për kontrollin e cilësisë së kodit - më parë ne e bënim atë manualisht, vetëm rishikimi i kodit. Por vëllimi në rritje i punës kërkon automatizimin e këtij procesi. Përveç kësaj, ka edhe punonjës të papërvojë në ekip, të cilët nuk janë plotësisht të njohur me rregulloret e brendshme të zhvillimit dhe priren të bëjnë më shumë gabime. Për të kontrolluar cilësinë e kodit, u vendos të zbatohej një analizues statik. Meqenëse SonarQube është përdorur tashmë në disa sisteme NSD, nuk u desh shumë kohë për të zgjedhur. Më parë, kolegë nga divizione të tjera e përdorën atë për të analizuar kodin e mikroshërbimeve në sistemin Alameda (sistemi i kontabilitetit të depozitimit dhe kleringut të vetë NSD), në CFT (sistemi i informacionit për kontabilitetin, bilanc, përgatitjen e raportimit të detyrueshëm dhe të brendshëm), në disa të tjera sistemet . Për eksperimentim, vendosëm të fillojmë me versionin falas të SonarQube. Pra, le të kalojmë në rastin tonë.
Procesi i zbatimit
Ne kemi:
- montimi automatik i sistemit në TeamCity;
- konfiguroni procesin e ngarkimit të kodit nëpërmjet MergeRequest nga një degë e veçorive në degën kryesore në GitLab (procesi i zhvillimit sipas GitHub Flow);
- SonarQube është konfiguruar për të analizuar kodin për sistemin DPO sipas planit.
Qellimi jone: implementimi i analizës automatike të kodit në proceset CI/CD të AVE.
Duhet të personalizohet: procesi i kontrollit automatik të kodit nga një analizues statik me çdo MergeRequest në degën kryesore.
ato. fotografia e synuar është si më poshtë: sapo zhvilluesi ngarkon ndryshimet në degën e veçorive, fillon një kontroll automatik për gabime të reja në kod. Nëse nuk ka gabime, atëherë ndryshimet lejohen të pranohen, përndryshe gabimet do të duhet të korrigjohen. Tashmë në fazën fillestare, ne ishim në gjendje të identifikonim një numër të caktuar gabimesh në kod. Sistemi ka cilësime shumë fleksibël: mund të konfigurohet në mënyrë të tillë që të funksionojë për detyra specifike të zhvilluesve, për çdo sistem dhe stil programimi.
Konfigurimi i QualityGate në SonarQube
Analiza QualityGate është një gjë që lexojmë në zorrët e internetit. Fillimisht, ne përdorëm një qasje të ndryshme, më komplekse dhe, në disa mënyra, jo plotësisht korrekte. Së pari, ne e bëmë skanimin përmes SonarQube dy herë: skanuam degën e veçorive dhe degën ku do të bashkonim degën e veçorive, dhe më pas krahasuam numrin e gabimeve. Kjo metodë nuk ishte e qëndrueshme dhe jo gjithmonë jepte rezultatin e duhur. Dhe më pas mësuam se në vend që të ekzekutoni SonarQube dy herë, mund të vendosni një kufi në numrin e gabimeve të bëra (QualityGate) dhe të analizoni vetëm degën që ngarkoni dhe krahasoni.
Tani për tani, ne ende përdorim një kontroll mjaft primitiv të kodit. Duhet të theksohet se SonarQube nuk është në përputhje me disa gjuhë programimi, duke përfshirë Delphi. Për momentin, për sistemin tonë, ne analizojmë vetëm kodin PLSql.
Ajo funksionon si kjo:
- Ne analizojmë vetëm kodin PL/SQL për projektin tonë.
- QualityGate është konfiguruar në SonarQube në mënyrë që numri i gabimeve të mos rritet me kryerjen.
- Numri i gabimeve në ekzekutimin e parë ishte 229. Nëse ka më shumë gabime gjatë kryerjes, atëherë bashkimi nuk lejohet.
- Më tej, në varësi të korrigjimit të gabimeve, do të jetë e mundur të rikonfiguroni QualityGate.
- Ju gjithashtu mund të shtoni artikuj të rinj për analizë, për shembull, mbulimi i kodit me teste, etj.
Skema e punës:
Në komentet e skenarit, mund të shihni se numri i gabimeve në degën e veçorive nuk është rritur. Kështu që gjithçka është në rregull.
Butoni Merge bëhet i disponueshëm.
Në komentet e skenarit, mund të shihni se numri i gabimeve në degën e veçorive është bërë më se i lejuar. Pra, gjithçka është KEQ.
Butoni Merge është i kuq. Për momentin, nuk ka asnjë ndalim për ngarkimin e ndryshimeve në kodin e gabuar, por kjo bëhet në diskrecionin e zhvilluesit përgjegjës. Në të ardhmen, ju mund të parandaloni kryerjen e angazhimeve të tilla në degën kryesore.
Vetë-ballafaqimi me defektet
Më pas, duhet të kontrolloni të gjitha gabimet e zbuluara nga sistemi, sepse SonarQube analizon sipas standardeve të tij strikte. Ajo që ai e konsideron një gabim mund të mos jetë në të vërtetë një në kodin tonë. Prandaj, duhet të kontrolloni dhe të vini re nëse ky është me të vërtetë një gabim, ose nëse nuk ka nevojë të modifikoni në kushtet tona. Kështu, ne zvogëlojmë numrin e gabimeve. Me kalimin e kohës, sistemi do të mësojë të kuptojë këto nuanca.
Në çfarë kemi ardhur
Qëllimi ynë ishte të kuptonim nëse është e përshtatshme në rastin tonë transferimi i verifikimit të kodit në automatizim. Dhe rezultati i përmbushi pritjet. SonarQube na lejon të punojmë me gjuhët që na duhen, bën analiza mjaft kompetente dhe ka potencialin për të mësuar nga këshillat e zhvilluesve. Në përgjithësi, ne jemi të kënaqur me përvojën tonë të parë me SonarQube dhe planifikojmë të zhvillojmë më tej në këtë drejtim. Ne presim që në të ardhmen të jemi në gjendje të kursejmë më shumë kohë dhe përpjekje për rishikimin e kodit dhe ta përmirësojmë atë duke eliminuar faktorin njerëzor. Ndoshta në këtë proces do të zbulojmë mangësitë e platformës, ose, përkundrazi, do të sigurohemi edhe një herë që kjo është një gjë e lezetshme me potencial të madh.
Në këtë artikull përmbledhës, ne folëm për njohjen tonë me analizuesin statik SonarQube. Nëse keni pyetje, ju lutemi shkruani në komente. Nëse jeni të interesuar për këtë temë, në botimin e ri do të përshkruajmë më në detaje se si të vendosni gjithçka në mënyrë korrekte dhe të shkruani kodin për të bërë një kontroll të tillë.
Autori i tekstit:
Burimi: www.habr.com