Dëshirojmë të ndajmë përvojën tonë të implementimit të platformës për analizën dhe matjen e vazhdueshme të cilësisë së kodit SonarQube në proceset tashmë ekzistuese të zhvillimit të sistemit DPO (shtesë për sistemin e llogarive depoja-kliring «Alameda») të Depozitarit Kombëtar.
Depozitari Kombëtar (grupi i kompanive «Bursa e Moskës») është një nga kompanitë kyçe të infrastrukturës financiare, duke ruajtur dhe duke llogaritur përkatësitë e sigurive për emetues rusë dhe të huaj me një vlerë mbi 50 trilion rubla. Vëllimi në rritje i transaksioneve të kryera nga sistemi, si dhe zgjerimi i vazhdueshëm i funksionalitetit, kërkon ruajtjen e një cilësie të lartë të kodit burimor të sistemeve. Një nga mjetet për arritjen e kësaj është analizatori statik SonarQube. Në këtë artikull do të përshkruajmë përvojën e suksesshme të implementimit pa probleme të analizatorit statik SonarQube në proceset ekzistuese të zhvillimit të departamentit tonë.
Përmbledhje mbi departamentin
Në kompetencën tonë janë modulet e mëposhtme: pagesat për klientët e NRD, qarkullimi elektronik i dokumenteve (EDO), përpunimi i mesazheve të depozitave tregtare (regjistrimi i transaksioneve jashtë tregut), kanalet e bashkëpunimit elektronik mes klientëve dhe NRD, dhe shumë të tjera. Në përgjithësi, ka një sasi të madhe pune në anën teknike të veprimtarisë operative. Ne punojmë në bazë të kërkesave. Kërkesat e operacionistëve përpunohen nga analistët: ata mbledhin kërkesat e klientëve dhe na paraqesin vizionin e tyre për mënyrën se si kjo duhet të pasqyrohet në program. Më pas, skema standarde: zhvillimi i kodit – testimi – eksperienca operuese – dorëzimi i kodit në linjën produktive te klienti direkt.
Pse pikërisht SonarQube?
Kjo është përvoja e parë e departamentit tonë në implementimin e një platforme për kontrollin e cilësisë së kodit – më parë e bënim këtë manualisht, duke zhvilluar vetëm rishikime kodimi. Por volumi në rritje i punëve kërkon automatizimin e këtij procesi. Përveç kësaj, në ekip ka edhe punonjës të paexperiencë, të cilët nuk janë shumë të njohur me rregullat e brendshme të zhvillimit dhe kanë prirje për të bërë më shumë gabime. Për kontrollin e cilësisë së kodit, u vendos të implementohet një analizues statik. Duke marrë parasysh se SonarQube ishte përdorur tashmë në disa sisteme të NRD, nuk ishte e nevojshme një zgjedhje e gjatë. Më parë, kolegët nga departamente të tjera kishin analizuar kodin e mikrosistemeve në sistemin "Alameda" (sistemi i vetë zhvilluar i depozitimit dhe pastrimit të NRD), në CFT (sistemi informativ për mbajtjen e kontabilitetit, bilancit, dhe përgatitjen e raportimeve të detyrueshme dhe të brendshme), dhe në disa sisteme të tjera. Për eksperimente, vendosëm të fillojmë me versionin falas të SonarQube. Tani, le të kalojmë në rastin tonë.
Procesi i implementimit
Ne kemi:
- ndërtimi automatik i sistemit në TeamCity;
- procesi i ngarkimit të kodit është vendosur përmes MergeRequest nga dega feature në degen master në GitLab (procesi i zhvillimit sipas GitHub Flow);
- SonarQube, e cila është configuruar për analizën e kodit për sistemin DPO sipas një plani.
Qëllimi ynë: implementoni analizën automatike të kodit në proceset CI/CD të DPO.
Duhet të konfigurohet: procesi i kontrollit automatike të kodit me një analizues statik për çdo MergeRequest në degën kryesore.
Për shembull, skema qëllimore është kështu: sa herë që zhvilluesi ngarkon ndryshime në degën feature, aktivizohet një kontroll automat për gabime të reja në kod. Nëse nuk ka gabime, pranohet prania e ndryshimeve; ndryshe do të duhet të korigjohen gabimet. Që në fazat fillestare, arritëm të identifikonim një numër të caktuar gabimesh në kod. Sistemi ka konfigurime shumë fleksibël: mund të konfigurohet të punojë për detyrat specifike të zhvilluesve, për çdo sistem dhe stil programimi.
Konfigurimi i QualityGate në SonarQube
Analiza e QualityGate është një koncept që e gjetëm në thellësitë e internetit. Fillimisht, ne përdornim një qasje tjetër, më të komplikuar dhe nga ana e disa pikave të dukshme jo të saktë. Fillimisht, ne e kryenim dy herë skanimin përmes SonarQube: skanim për depon e veçorive dhe depon në të cilën planifikonim të dukej depon e veçorive, dhe pastaj krahasonim numrin e gabimeve. Ky metodë nuk ishte e qëndrueshme dhe nuk jepte gjithmonë rezultatet e sakta. Pastaj mësuam se është e mundur, në vend të dyshimesh të SonarQube, të vendosim një kufi për numrin e gabimeve të pranueshme (QualityGate) dhe të analizojmë vetëm atë degë që po e ngarkojmë dhe krahasojmë.
Ende po përdorim një verifikim të thjeshtë të kodit. Është e rëndësishme të theksojmë se SonarQube nuk është i pajtueshëm me disa gjuhë programimi, përfshirë Delphi. Aktuali, për sistemin tonë, po analizojmë vetëm kodin PLSql.
Funksionon kështu:
- Ne analizojmë vetëm kodin PL/SQL për projektin tonë.
- Në SonarQube është konfiguruar QualityGate në mënyrë që numri i gabimeve të mos rritet me komitin.
- Numri i gabimeve gjatë fillimit të parë ishte 229. Nëse numri i gabimeve gjatë komitit rritet, atëherë merge nuk lejohet.
- Më pas, nëse korrigjohen gabimet, do të jetë e mundur të riparohen cilësitë.
- Po ashtu, mund të shtoni pikë të reja për analizë, si mbulimi i kodit nga testet etj.
Skema e punës:
Në komentet e punës së skriptit është e qartë se numri i gabimeve në degën feature nuk është rritur. Do të thotë se gjithçka është në rregull.
Të krijohet butoni Merge.
Në komentet e punës së skriptit tregohet se numri i gabimeve në degën feature ka tejkaluar limitin e lejuar. Do të thotë se gjithçka është KEQ.
Butoni Merge është i kuq. Për momentin nuk ka ndalesë për të bërë ndryshime në kodin me gabime, por kjo bëhet sipas vendimit të zhvilluesit përgjegjës. Në të ardhmen, mund të ndalohet ndarja e këtij lloji të komiteteve në degën kryesore.
Punë e pavarur mbi gabimet
Më pas, është e nevojshme të kontrolloni të gjithë gabimet e identifikuara nga sistemi, sepse SonarQube analizon sipas standardeve të tij të rrepta. Ajo që ai e sheh si gabim, në kodin tonë mund të mos jetë një gabim real. Prandaj, është e domosdoshme të kontrolloni dhe të shënoni nëse është vërtet një gabim, apo nëse nuk ka nevojë për rregullime në kushtet tona. Kështu, ne reduktojmë numrin e gabimeve. Me kalimin e kohës, sistemi do të mësojë të kuptojë këto nuanca.
Ku çfarë kemi arritur
Qëllimi ynë ishte të kuptonim nëse ishte e arsyeshme të automatisonim kontrollin e kodit. Dhe rezultati na ka përmbushur pritshmëritë. SonarQube na lejon të punojmë me gjuhët që na nevojiten, bën një analizë mjaft të mirë dhe ka potencialin të mësojë nga sugjerimet e zhvilluesve. Në përgjithësi, ne jemi të kënaqur me përvojën tonë të parë me SonarQube dhe planifikojmë të zhvillohemi më tej në këtë drejtim. Presim që në të ardhmen të mund të kursejmë më shumë kohë dhe përpjekje në kontrollin e kodit dhe të bëjmë atë më cilësore, duke eliminuar faktorët njerëzorë. Mund të zbulojmë mangësitë e platformës gjatë procesit ose, përkundrazi, të konfirmojmë edhe një herë se kjo është një gjë e shkëlqyer me potencial të madh.
Në këtë artikull të shqyrtimit ne treguam për njohjen tonë me analizuesin statik SonarQube. Nëse keni pyetje, ju lutemi shkruani në komentet. Nëse jeni të interesuar për këtë temë, në publikimin e ri ne do ta përshkruajmë më në detaje se si ta konfigurojmë gjithçka si duhet dhe të shkruajmë kodin për të bërë një kontroll të tillë.
Autori i tekstit:
Burimi: habr.com
