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
