Nais naming ibahagi ang aming karanasan sa pagpapatupad ng platform para sa tuluy-tuloy na pagsusuri at pagsukat ng kalidad ng SonarQube code sa mga kasalukuyang proseso para sa pagbuo ng DPO system (isang karagdagan sa Alameda depositary at clearing accounting system) ng National Settlement Depository.
Ang National Settlement Depository (Moscow Exchange Group of Companies) ay isa sa mga pangunahing kumpanya ng imprastraktura sa pananalapi na nag-iimbak at nagtatala ng mga seguridad ng mga taga-isyu ng Russia at dayuhan na nagkakahalaga ng higit sa 50 trilyong rubles. Ang lumalaking dami ng mga operasyon na isinasagawa ng system, pati na rin ang patuloy na pagtaas sa pag-andar, ay nangangailangan ng pagpapanatili ng mataas na kalidad ng source code ng mga system. Isa sa mga tool upang makamit ang layuning ito ay ang SonarQube static analyzer. Sa artikulong ito, inilalarawan namin ang matagumpay na karanasan ng walang putol na pagpapatupad ng SonarQube static analyzer sa mga kasalukuyang proseso ng development ng aming departamento.
Maikling tungkol sa departamento
Kasama sa aming kakayahan ang mga sumusunod na module: mga pagbabayad sa mga kliyente ng NSD, pamamahala ng elektronikong dokumento (EDF), pagpoproseso ng mga mensahe ng trade repository (pagpaparehistro ng mga transaksyon sa labas ng palitan), mga channel ng elektronikong pakikipag-ugnayan sa pagitan ng mga kliyente at NSD, at marami pa. Sa pangkalahatan, isang malaking layer ng trabaho sa teknikal na bahagi ng mga operasyon. Nagtatrabaho kami batay sa mga aplikasyon. Ang mga aplikasyon ng mga teller ay pinoproseso ng mga analyst: kinokolekta nila ang mga kinakailangan ng customer at ipinakita sa amin ang kanilang pananaw kung paano ito dapat magkasya sa programa. Dagdag pa, ang karaniwang pamamaraan: pagbuo ng code - pagsubok - operasyon ng pagsubok - paghahatid ng code sa produktibong circuit sa direktang customer.
Bakit SonarQube?
Ito ang unang karanasan ng aming departamento sa pagpapatupad ng isang platform para sa kontrol sa kalidad ng code - dati ay ginawa namin ito nang manu-mano, ang pagsusuri lamang ng code. Ngunit ang lumalaking dami ng trabaho ay nangangailangan ng automation ng prosesong ito. Bilang karagdagan, mayroon ding mga walang karanasan na empleyado sa koponan na hindi lubos na pamilyar sa mga panloob na regulasyon sa pag-unlad at malamang na gumawa ng higit pang mga pagkakamali. Upang makontrol ang kalidad ng code, napagpasyahan na ipatupad ang isang static analyzer. Dahil ang SonarQube ay nagamit na sa ilang NSD system, hindi nagtagal upang pumili. Dati, ginamit ito ng mga kasamahan mula sa ibang mga dibisyon upang pag-aralan ang code ng mga microservice sa Alameda system (sariling depository at clearing accounting system ng NSD), sa CFT (sistema ng impormasyon para sa accounting, balanse, paghahanda ng mandatory at panloob na pag-uulat), sa ilang iba pa. mga sistema. Para sa eksperimento, nagpasya kaming magsimula sa libreng bersyon ng SonarQube. Kaya't magpatuloy tayo sa ating kaso.
Proseso ng pagpapatupad
Mayroon kaming:
- awtomatikong pagpupulong ng system sa TeamCity;
- i-set up ang proseso ng pag-upload ng code sa pamamagitan ng MergeRequest mula sa isang feature branch patungo sa master branch sa GitLab (proseso ng development ayon sa GitHub Flow);
- Na-configure ang SonarQube upang pag-aralan ang code para sa sistema ng DPO sa iskedyul.
Ang aming layunin: ipatupad ang awtomatikong pagsusuri ng code sa mga proseso ng CI/CD ng AVE.
Kailangang i-customize: ang proseso ng awtomatikong pagsuri sa code ng isang static na analyzer sa bawat MergeRequest sa pangunahing sangay.
Yung. ang target na larawan ay ang mga sumusunod: sa sandaling mag-upload ang developer ng mga pagbabago sa sangay ng tampok, magsisimula ang isang awtomatikong pagsusuri para sa mga bagong error sa code. Kung walang mga error, ang mga pagbabago ay pinapayagang tanggapin, kung hindi, ang mga error ay kailangang itama. Nasa paunang yugto na, natukoy namin ang isang tiyak na bilang ng mga error sa code. Ang system ay may napaka-flexible na mga setting: maaari itong i-configure sa paraang gumagana ito para sa mga partikular na gawain ng mga developer, para sa bawat sistema at istilo ng programming.
Pag-configure ng QualityGate sa SonarQube
Ang pagsusuri sa QualityGate ay isang bagay na nababasa natin sa laman ng Internet. Sa una, gumamit kami ng ibang diskarte, mas kumplikado at kahit papaano ay hindi masyadong tama. Una, pinatakbo namin ang pag-scan sa SonarQube nang dalawang beses: na-scan namin ang sangay ng tampok at ang sangay kung saan namin pagsasamahin ang sangay ng tampok, at pagkatapos ay ikinumpara namin ang bilang ng mga error. Ang pamamaraang ito ay hindi matatag at hindi palaging nagbibigay ng tamang resulta. At pagkatapos ay nalaman namin na sa halip na patakbuhin ang SonarQube nang dalawang beses, maaari kang magtakda ng limitasyon sa bilang ng mga error na nagawa (QualityGate) at suriin lamang ang sangay na iyong ina-upload at ihahambing.
Sa ngayon, gumagamit pa rin kami ng medyo primitive code check. Dapat tandaan na ang SonarQube ay hindi tugma sa ilang mga programming language, kabilang ang Delphi. Sa ngayon, para sa aming system, sinusuri lang namin ang PLSql code.
Ito ay gumagana tulad nito:
- Sinusuri lamang namin ang PL/SQL code para sa aming proyekto.
- Ang QualityGate ay na-configure sa SonarQube upang ang bilang ng mga error ay hindi tumaas sa commit.
- Ang bilang ng mga error sa unang pagtakbo ay 229. Kung mayroong higit pang mga error sa panahon ng commit, hindi pinapayagan ang pagsasama.
- Dagdag pa, napapailalim sa pagwawasto ng mga error, posibleng muling i-configure ang QualityGate.
- Maaari ka ring magdagdag ng mga bagong item para sa pagsusuri, halimbawa, saklaw ng code na may mga pagsubok, atbp.
Scheme ng trabaho:
Sa mga komento ng script, makikita mo na hindi tumaas ang bilang ng mga error sa feature branch. Kaya lahat ay OK.
Magiging available ang button na Pagsamahin.
Sa mga komento ng script, makikita mo na ang bilang ng mga error sa sangay ng tampok ay naging higit sa pinapayagan. Kaya lahat ay MASAMA.
Ang pindutan ng Pagsamahin ay pula. Sa ngayon, walang pagbabawal sa pag-upload ng mga pagbabago sa maling code, ngunit ginagawa ito sa pagpapasya ng responsableng developer. Sa hinaharap, maaari mong pigilan ang mga naturang commit na gawin sa pangunahing sangay.
Self-pagharap sa mga bug
Susunod, kailangan mong suriin ang lahat ng mga error na nakita ng system, dahil sinusuri ng SonarQube ayon sa mahigpit na pamantayan nito. Ang itinuturing niyang error ay maaaring hindi talaga isa sa aming code. Samakatuwid, kailangan mong suriin at tandaan kung ito ay talagang isang pagkakamali, o kung hindi na kailangang i-edit sa aming mga kundisyon. Kaya, binabawasan namin ang bilang ng mga error. Sa paglipas ng panahon, matututunan ng system na maunawaan ang mga nuances na ito.
Ano ang narating natin
Ang aming layunin ay upang maunawaan kung ito ay kapaki-pakinabang sa aming kaso upang ilipat ang pag-verify ng code sa automation. At ang resulta ay naaayon sa inaasahan. Binibigyang-daan kami ng SonarQube na magtrabaho kasama ang mga wikang kailangan namin, gumagawa ng medyo karampatang pagsusuri, at may potensyal na matuto mula sa mga tip ng developer. Sa pangkalahatan, nalulugod kami sa aming unang karanasan sa SonarQube at nagpaplanong umunlad pa sa direksyong ito. Inaasahan namin na sa hinaharap ay makakatipid kami ng mas maraming oras at pagsisikap sa pagsusuri ng code at gagawin itong mas mahusay sa pamamagitan ng pag-aalis ng human factor. Marahil sa proseso ay matutuklasan natin ang mga pagkukulang ng platform, o, sa kabaligtaran, sisiguraduhin nating muli na ito ay isang cool na bagay na may malaking potensyal.
Sa artikulong ito ng pangkalahatang-ideya, napag-usapan namin ang tungkol sa aming kakilala sa SonarQube static analyzer. Kung mayroon kang mga katanungan, mangyaring sumulat sa mga komento. Kung interesado ka sa paksang ito, sa bagong publikasyon ay ilalarawan namin nang mas detalyado kung paano i-set up nang tama ang lahat at magsulat ng code upang gawin ang naturang tseke.
May-akda ng teksto:
Pinagmulan: www.habr.com