Am dori să împărtășim experiența noastră de implementare a unei platforme de analiză și măsurare continuă a calității codului SonarQube în procesele existente de dezvoltare a sistemului DPO (o completare la depozitarul Alameda și sistemul de contabilitate de compensare) al Depozitarului Național al Decontărilor.
Depozitarul Național al Decontărilor (Grupul de Companii al Bursei din Moscova) este una dintre companiile cheie de infrastructură financiară care stochează și înregistrează valori mobiliare ale emitenților ruși și străini în valoare de peste 50 de trilioane de ruble. Volumul tot mai mare de operațiuni efectuate de sistem, precum și creșterea continuă a funcționalității, impun menținerea calității înalte a codului sursă al sistemelor. Unul dintre instrumentele pentru atingerea acestui obiectiv este analizorul static SonarQube. În acest articol, descriem experiența de succes a implementării fără probleme a analizorului static SonarQube în procesele de dezvoltare existente ale departamentului nostru.
Pe scurt despre departament
Competența noastră include următoarele module: plăți către clienții NSD, managementul documentelor electronice (EDF), procesarea mesajelor din registrul de tranzacții (înregistrarea tranzacțiilor în afara bursei), canale electronice de interacțiune între clienți și NSD și multe altele. În general, un strat mare de muncă pe partea tehnică a operațiunilor. Lucrăm pe bază de aplicații. Aplicațiile casierului sunt procesate de analiști: aceștia colectează cerințele clienților și ne prezintă viziunea lor despre cum ar trebui să se încadreze în program. Mai departe, schema standard: dezvoltarea codului - testarea - operarea de probă - livrarea codului către circuitul productiv către clientul direct.
De ce SonarQube?
Aceasta este prima experiență a departamentului nostru în implementarea unei platforme pentru controlul calității codului - anterior o făceam manual, doar revizuirea codului. Dar volumul tot mai mare de muncă necesită automatizarea acestui proces. În plus, în echipă există și angajați fără experiență care nu sunt în totalitate familiarizați cu reglementările interne de dezvoltare și tind să facă mai multe greșeli. Pentru a controla calitatea codului, s-a decis implementarea unui analizor static. Deoarece SonarQube a fost deja folosit în unele sisteme NSD, nu a durat mult să alegeți. Anterior, colegii din alte divizii îl foloseau pentru a analiza codul microserviciilor din sistemul Alameda (sistemul propriu de depozitare și de compensare contabilă al NSD), în CFT (sistemul informațional pentru contabilitate, bilanț, întocmirea raportării obligatorii și interne), în unele alte sisteme . Pentru experimentare, am decis să începem cu versiunea gratuită a SonarQube. Deci, să trecem la cazul nostru.
Proces de implementare
Avem:
- asamblarea automată a sistemului în TeamCity;
- configurați procesul de încărcare a codului prin MergeRequest de la o ramură caracteristică la ramura principală în GitLab (proces de dezvoltare conform GitHub Flow);
- SonarQube a fost configurat să analizeze codul pentru sistemul DPO la program.
Scopul nostru: implementarea analizei automate a codului în procesele CI/CD ale AVE.
Trebuie personalizat: procesul de verificare automată a codului de către un analizor static cu fiecare MergeRequest către ramura principală.
Acestea. imaginea țintă este următoarea: de îndată ce dezvoltatorul încarcă modificări în ramura caracteristică, începe o verificare automată pentru noi erori în cod. Dacă nu există erori, atunci modificările pot fi acceptate, în caz contrar erorile vor trebui corectate. Deja în etapa inițială, am putut identifica un anumit număr de erori în cod. Sistemul are setări foarte flexibile: poate fi configurat în așa fel încât să funcționeze pentru sarcini specifice ale dezvoltatorilor, pentru fiecare sistem și stil de programare.
Configurarea QualityGate în SonarQube
Analiza QualityGate este un lucru pe care îl citim în măruntaiele internetului. Inițial, am folosit o abordare diferită, mai complexă și, în unele privințe, nu în totalitate corectă. Mai întâi, am rulat scanarea prin SonarQube de două ori: am scanat ramura caracteristică și ramura în care urma să îmbinam ramura caracteristică, apoi am comparat numărul de erori. Această metodă nu a fost stabilă și nu a dat întotdeauna rezultatul corect. Și apoi am aflat că în loc să rulați SonarQube de două ori, puteți stabili o limită a numărului de erori făcute (QualityGate) și să analizați doar ramura pe care o încărcați și să o comparați.
Deocamdată, folosim încă o verificare a codului destul de primitivă. Trebuie remarcat faptul că SonarQube nu este compatibil cu unele limbaje de programare, inclusiv Delphi. Momentan, pentru sistemul nostru, analizăm doar cod PLSql.
Funcționează așa:
- Analizăm doar codul PL/SQL pentru proiectul nostru.
- QualityGate este configurat în SonarQube, astfel încât numărul de erori să nu crească odată cu comiterea.
- Numărul de erori la prima rulare a fost 229. Dacă există mai multe erori în timpul comiterii, atunci îmbinarea nu este permisă.
- În plus, sub rezerva corectării erorilor, va fi posibilă reconfigurarea QualityGate.
- De asemenea, puteți adăuga elemente noi pentru analiză, de exemplu, acoperirea codului cu teste etc.
Schema de lucru:
În comentariile scriptului, puteți vedea că numărul de erori în ramura caracteristică nu a crescut. Deci totul este OK.
Butonul Merge devine disponibil.
În comentariile scriptului, puteți vedea că numărul de erori din ramura caracteristică a devenit mai mult decât permis. Deci totul este RĂU.
Butonul Merge este roșu. În prezent, nu există nicio interdicție privind încărcarea modificărilor la codul eronat, dar acest lucru se face la discreția dezvoltatorului responsabil. În viitor, puteți preveni efectuarea unor astfel de comiteri către ramura principală.
Auto-tratarea cu bug-uri
În continuare, trebuie să verificați toate erorile detectate de sistem, deoarece SonarQube analizează conform standardelor sale stricte. Ceea ce el consideră o eroare poate să nu fie de fapt una din codul nostru. Prin urmare, trebuie să verificați și să observați dacă aceasta este într-adevăr o greșeală sau dacă nu este nevoie să editați î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 în cazul nostru să transferăm verificarea codului în automatizare. Iar rezultatul a fost la înălțimea așteptărilor. SonarQube ne permite să lucrăm cu limbile de care avem nevoie, face analize destul de competente și are potențialul de a învăța din sfaturile 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ă putem economisi mai mult timp și efort la revizuirea codului și să o îmbunătățim prin eliminarea factorului uman. Poate că în acest proces vom descoperi neajunsurile platformei sau, dimpotrivă, ne vom asigura încă o dată că acesta este un lucru mișto cu mare potențial.
În acest articol de prezentare generală, am vorbit despre cunoașterea noastră cu analizorul static SonarQube. Dacă aveți întrebări, vă rugăm să scrieți în comentarii. Dacă sunteți interesat de acest subiect, în noua publicație vom descrie mai detaliat cum să configurați totul corect și să scrieți cod pentru a face o astfel de verificare.
Autor text:
Sursa: www.habr.com