Како го имплементиравме SonarQube и го реализиравме неговиот голем потенцијал

Сакаме да го споделиме нашето искуство за имплементирање на платформата SonarQube за континуирана анализа и мерење на квалитетот на кодот во постојните развојни процеси на системот DPO (дополнување на депозитниот и клириншкиот сметководствен систем Alameda) на Националниот депозитар за порамнување.

Националниот депозитар за порамнување (Москва берза група на компании) е една од клучните компании во финансиската инфраструктура, складирање и сметководство за хартии од вредност на руски и странски издавачи во вредност од повеќе од 50 трилиони рубли. Зголемениот обем на операции што ги врши системот, како и континуираното проширување на функционалноста, бараат одржување на висококвалитетен изворен код на системите. Една алатка за постигнување на оваа цел е статичкиот анализатор SonarQube. Во оваа статија ќе го опишеме успешното искуство за беспрекорно имплементирање на статичкиот анализатор SonarQube во постоечките развојни процеси на нашиот оддел.

Накратко за одделот

Нашата компетентност ги вклучува следните модули: плаќања до клиенти на NSD, управување со електронски документи (EDF), обработка на пораки во складиштето за трговија (регистрација на трансакции преку шалтер), канали за електронска интеракција помеѓу клиентите и NSD и многу повеќе. Генерално, треба многу да се работи на техничката страна на оперативните активности. Работиме врз основа на барања. Апликациите од оперативните службеници ги обработуваат аналитичарите: тие ги собираат барањата на клиентите и ни ја презентираат нивната визија за тоа како треба да се вклопи во програмата. Следна е стандардната шема: развој на код - тестирање - пробна работа - испорака на кодот до производното коло до директниот клиент.

Зошто SonarQube?

Ова е прво искуство на нашиот оддел во имплементирање на платформа за контрола на квалитетот на кодот - претходно тоа го правевме рачно, правејќи само прегледи на кодови. Но, зголемениот обем на работа бара автоматизација на овој процес. Покрај тоа, тимот вклучува и неискусни вработени кои не се целосно запознаени со прописите за внатрешниот развој и имаат тенденција да прават повеќе грешки. За да се контролира квалитетот на кодот, беше одлучено да се имплементира статички анализатор. Бидејќи SonarQube веќе се користеше во некои NSD системи, немаше долг избор. Претходно, колегите од другите оддели го користеа за да го анализираат кодот на микроуслугите во системот Аламеда (сопствениот депозитен и клириншки сметководствен систем на NSD), во CFT (информациски систем за водење сметководство, биланси, подготовка на задолжително и внатрешно известување), во некои други системи. За експерименти, решивме да започнеме со бесплатната верзија на SonarQube. Па да продолжиме со нашиот случај.

Процес на имплементација

Ние имаме:

• автоматско склопување на системот во TeamCity;
• конфигуриран е процесот на испраќање код преку MergeRequest од гранката на функции во главната гранка во GitLab (процес на развој според GitHub Flow);
• SonarQube, конфигуриран да го анализира кодот за системот DPO на распоред.

Нашата цел: спроведување автоматска анализа на кодови во процесите на CI/CD на DPO.

Треба да се конфигурира: процес на автоматска проверка на кодот со статички анализатор со секое MergeRequest до главната гранка.

Оние. Целната слика е следна: штом развивачот ќе постави промени во гранката на функциите, се стартува автоматска проверка за нови грешки во кодот. Ако нема грешки, тогаш промените се дозволени да се прифатат, во спротивно грешките ќе треба да се поправат. Веќе во почетната фаза успеавме да идентификуваме одреден број на грешки во кодот. Системот има многу флексибилни поставки: може да се конфигурира на таков начин што работи за специфичните задачи на програмерите, за секој систем и стил на програмирање.

Поставување QualityGate во SonarQube

Анализата на QualityGate е нешто што го читаме во длабочините на Интернет. Првично користевме поинаков пристап, покомплексен и, на некој начин, не сосема точен. Прво, двапати го извршивме скенирањето преку SonarQube: ја скениравме гранката на функции и гранката каде што требаше да ја споиме гранката на функции, а потоа го споредивме бројот на грешки. Овој метод не беше стабилен и не секогаш даваше правилен резултат. И тогаш дознавме дека наместо да работиме двапати на SonarQube, можеме да поставиме ограничување на бројот на направени грешки (QualityGate) и да ја анализираме само гранката што ја прикачувате и споредувате.

Засега сè уште користиме прилично примитивен преглед на кодот. Вреди да се напомене дека SonarQube не е компатибилен со некои програмски јазици, вклучувајќи го и Delphi. Во моментов, анализираме само PLSql код за нашиот систем.

Работи вака:

• Ние анализираме само PL/SQL код за нашиот проект.
• SonarQube има QualityGate конфигуриран така што бројот на грешки не се зголемува со извршување.
• Бројот на грешки при првото лансирање беше 229. Ако има повеќе грешки при извршување, тогаш спојувањето не е дозволено.
• Понатаму, ако грешките се поправат, ќе биде можно повторно да се конфигурира QualityGate.
• Можете исто така да додадете нови точки за анализа, на пример, покривање на код со тестови итн.

Шема на работа:

Коментарите на сценариото покажуваат дека бројот на грешки во гранката на функции не е зголемен. Значи се е во ред.

Копчето Спојување станува достапно.

Во коментарите на сценариото, можете да видите дека бројот на грешки во гранката на функции стана повеќе од прифатлив. Значи се е ЛОШО.

Копчето за спојување е црвено. Во моментов, нема забрана за поставување промени врз основа на погрешен код, но тоа се прави по дискреција на одговорниот развивач. Во иднина, можете да спречите додавање на такви обврски во главната гранка.

Самостојна работа на грешки

Следно, треба да ги проверите сите грешки откриени од системот, бидејќи SonarQube анализира според неговите строги стандарди. Она што тој го смета за грешка можеби всушност не е грешка во нашиот код. Затоа, треба да проверите и да забележите дали ова е навистина грешка или нема потреба од уредување во наши услови. На овој начин го намалуваме бројот на грешки. Со текот на времето, системот ќе научи да ги разбира овие нијанси.

До што дојдовме

Нашата цел беше да разбереме дали би било препорачливо во нашиот случај да го пренесеме прегледот на кодот на автоматизација. И резултатот ги оправда очекувањата. SonarQube ни овозможува да работиме со јазиците што ни се потребни, прави прилично компетентна анализа и има потенцијал да учиме од совети за програмери. Генерално, задоволни сме од нашето прво искуство со користење на SonarQube и планираме да се развиваме понатаму во оваа насока. Очекуваме дека во иднина ќе можеме да заштедиме повеќе време и напор за преглед на кодот и да го подобриме со елиминирање на човечкиот фактор. Можеби во тој процес ќе ги откриеме недостатоците на платформата или, обратно, уште еднаш ќе се увериме дека ова е кул работа со голем потенцијал.

Во оваа статија за преглед зборувавме за нашето запознавање со статичкиот анализатор SonarQube. Ако имате прашања, ве молиме пишете во коментарите. Ако сте заинтересирани за оваа тема, во нова публикација ќе опишеме подетално како да поставите сè правилно и да напишете код за да направите таква проверка.

Автор на текстот: атања

Извор: www.habr.com