Dorim să împărtășim experiența implementării platformei pentru analiza și măsurarea continuă a calității codului SonarQube în procesele existente de dezvoltare a sistemului DPO (complement al sistemului de contabilitate de decontare «Alameda») al Depozitarului Național.
Depozitarul Național (grupul de companii «Bursa din Moscova») este una dintre companiile cheie ale infrastructurii financiare, păstrează și contabilizează valori mobiliare emise de entități rusești și străine în valoare totală de peste 50 trilioane ruble. Volumul în creștere al operațiunilor efectuate de sistem și extinderea continuă a funcționalității necesită menținerea unei calități ridicate a codului sursă al sistemelor. Unul dintre instrumentele pentru atingerea acestui obiectiv este analizatorul static SonarQube. În acest articol, vom descrie experiența noastră de succes în integrarea perfectă a analizatorului static SonarQube în procesele existente de dezvoltare ale departamentului nostru.
Câteva informații despre departament
În competența noastră se află următoarele module: plăți către clienții NRD, circulația documentelor electronice (EDE), prelucrarea mesajelor din depozitul de valori (înregistrarea tranzacțiilor OTC), canale de interacțiune electronică între clienți și NRD și multe altele. În general, ne ocupăm de o gamă largă de lucrări pe partea tehnică a activităților operaționale. Lucrăm pe baza cererilor. Cererile operatorilor sunt procesate de analiști: aceștia adună cerințele clientului și ne prezintă viziunea lor despre cum ar trebui să fie implementat în program. Apoi, schema standard: dezvoltarea codului – testare – operare de probă – livrarea codului pe circuitul de producție clientului direct.
De ce SonarQube?
Aceasta este prima experiență a departamentului nostru în implementarea unei platforme pentru controlul calității codului – anterior, făceam acest lucru manual, realizând doar revizuiri de cod. Însă volum enorm de muncă necesită automatizarea acestui proces. În plus, echipa include și angajați mai puțin experimentați, care nu sunt familiarizați cu reglementările interne de dezvoltare și tind să facă mai multe erori. Pentru controlul calității codului, s-a decis implementarea unui analist static. Deoarece SonarQube a fost deja utilizat în anumite sisteme NРD, alegerea a fost rapidă. Anterior, colegii din alte departamente au analizat astfel codul microserviciilor în sistemul „Alameda” (sistemul propriu de contabilitate de depozitare și de clearing NРD), în CFT (sistem informațional pentru gestionarea contabilității, bilanțului, pregătirea raportării obligatorii și interne), și în alte câteva sisteme. Pentru experimente, am decis să începem cu versiunea gratuită SonarQube. Așadar, să trecem la cazul nostru.
Procesul de implementare
Avem:
- compilarea automată a sistemului în TeamCity;
- procesul de încărcare a codului este configurat prin MergeRequest din ramura feature în ramura master în GitLab (proces de dezvoltare conform GitHub Flow);
- SonarQube, configurat pentru analiza codului pentru sistemul DPO conform unui program.
Scopul nostru: a implementa analiza automată a codului în procesele CI/CD ale DPO.
Trebuie configurat: procesul de verificare automată a codului cu ajutorul analistului static la fiecare MergeRequest în ramura principală.
Adică, imaginea țintă este următoarea: odată ce un dezvoltator încarcă modificările în ramura feature, se inițiază o verificare automată pentru erorile noi din cod. Dacă nu există erori, modificările sunt acceptate, în caz contrar trebuie corectate erorile. Chiar și în etapa inițială, am putut identifica un număr semnificativ de erori în cod. Sistemul are setări foarte flexibile: poate fi configurat astfel încât să funcționeze pentru sarcinile specifice ale dezvoltatorilor, pentru fiecare sistem și stil de programare.
Configurarea QualityGate în SonarQube
Analiza QualityGate este un lucru pe care l-am descoperit în adâncurile internetului. Inițial am folosit o altă abordare, mai complexă și oarecum incorectă. La început, ruleam de două ori scanarea prin SonarQube: scaneam ramura feature și ramura în care intenționam să îmbinăm ramura feature, apoi comparăm numărul de erori. Această metodă nu era stabilă și nu oferea întotdeauna un rezultat corect. Apoi am aflat că în loc de un dublu proces SonarQube, putem stabili un limită asupra numărului de erori acceptabile (QualityGate) și analiza doar ramura pe care o încarci și o compari.
Până acum, folosim o verificare a codului destul de primitivă. Merită menționat că SonarQube nu este compatibil cu anumite limbaje de programare, inclusiv Delphi. În prezent, pentru sistemul nostru analizăm doar cod PLSql.
Funcționează astfel:
- Analizăm pentru proiectul nostru doar cod PL/SQL.
- În SonarQube, QualityGate este configurat astfel încât numărul de erori să nu crească odată cu un commit.
- Numărul de erori la primul nostru rulaj a fost de 229. Dacă numărul de erori în timpul commit-ului crește, atunci merge-ul nu este permis.
- Apoi, cu condiția de a corecta erorile, se poate reconfigura QualityGate.
- De asemenea, se pot adăuga noi puncte pentru analiză, cum ar fi acoperirea codului cu teste etc.
Schema de lucru:
În comentariile execuției scriptului se poate vedea că numărul de erori în ramura feature nu a crescut. Asta înseamnă că totul este în regulă.
Devine disponibil butonul Merge.
În comentariile execuției scriptului se poate observa că numărul de erori în ramura feature a depășit limita acceptabilă. Asta înseamnă că totul este RĂU.
Butonul Merge este roșu. În prezent, nu există nicio restricție pentru a încărca modificări pe un cod eronat, dar aceasta se face la discreția dezvoltatorului responsabil. În viitor, se poate interzice introducerea unor astfel de commit-uri în ramura principală.
Lucru independent asupra erorilor.
Apoi, este necesar să verifici toate erorile identificate de sistem, deoarece SonarQube analizează conform standardelor sale stricte. Ceea ce el consideră o eroare, poate să nu fie cu adevărat în codul nostru. Prin urmare, este important să verificăm și să marcăm dacă este cu adevărat o eroare sau dacă nu este necesar să facem modificări în condițiile noastre. Astfel, reducem numărul de erori. În timp, sistemul va învăța să înțeleagă aceste nuanțe.
La ce am ajuns
Scopul nostru a fost să înțelegem dacă este oportun să traducem automatizarea verificării codului în cazul nostru. Și rezultatul a fost pe măsura așteptărilor. SonarQube ne permite să lucrăm cu limbajele de care avem nevoie, oferă o analiză destul de competentă și are potențialul de a învăța din sugestiile dezvoltatorilor. În general, suntem mulțumiți de prima noastră experiență cu SonarQube și intenționăm să ne dezvoltăm în continuare în această direcție. Ne așteptăm ca în viitor să economisim mai mult timp și efort în verificarea codului și să o facem mai calitativ, eliminând factorul uman. Este posibil ca în proces să descoperim neajunsuri ale platformei sau, dimpotrivă, să ne convingem din nou că aceasta este o unealtă grozavă cu un mare potențial.
În acest articol de revizuire, am povestit despre întâlnirea noastră cu analizele statice SonarQube. Dacă aveți întrebări, vă rugăm să le scrieți în comentarii. Dacă sunteți interesat de acest subiect, în publicația următoare vom detalia cum să configurăm corect totul și să scriem cod pentru a efectua această verificare.
Autorul textului:
Sursa: habr.com
