Как внедрихме SonarQube и осъзнахме неговия голям потенциал

Искаме да споделим опит с внедряването на платформата за непрекъснат анализ и измерване на качеството на кода SonarQube в съществуващите процеси на разработка на системата ДПО (допълнение към системата за депозитарно-клирингово отчитане "Аламеда") на Националния расчетен депозитар.

Националният расчетен депозитар (група компании "Московска борса") е една от ключовите компании във финансовата инфраструктура, съхранява и отбелязва ценни книжа на руски и чуждестранни емитенти на стойност над 50 трлн рубли. Растящият обем на операциите, извършвани от системата, както и непрекъснатото разширяване на функционалността изискват поддържане на високо качество на изходния код на системите. Един от инструментите за постигане на тази цел е статичният анализатор SonarQube. В тази статия ще опишем успешния опит за безпроблемно внедряване на статичния анализатор SonarQube в съществуващите процеси на разработка в нашия отдел.

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

В нашата компетенция са следните модули: плащания на клиентите на НРД, електронен документооборот (ЕДО), обработка на съобщения от търговския депозитар (регистрация на извънборсови сделки), канали за електронно взаимодействие между клиенти и НРД и много други. В общи линии, голямо количество работа по техническата страна на оперативната дейност. Работим на основата на заявки. Заявките на операторите се обработват от анализатори: те събират изискванията на клиента и ни представят своето виждане за това как да бъде интегрирано в програмата. Следват стандартните стъпки: разработка на код – тестване – опитна експлоатация – доставка на кода за продуктивния контур на непосредствения клиент.

Защо точно SonarQube?

Това е първият опит на нашия отдел за внедряване на платформа за контрол на качеството на кода – преди това го правехме ръчно, провеждайки само кодови ревюта. Но увеличаващият се обем работа изисква автоматизация на този процес. Освен това, в екипа има и неопитни служители, които не са напълно запознати с вътрешните регламенти на разработката и често допускат повече грешки. За контрол на качеството на кода беше решено да се внедри статичен анализатор. Тъй като SonarQube вече е използван в някои системи на НРД, изборът не отне дълго време. По-рано колегите от други подразделения анализираха с помощта на него кода на микросервизите в системата „Аламена“ (собствена система за депозитарно-клирингово отчитане на НРД), в ЦФТ (информационна система за водене на счетоводство, баланс, подготовка на задължителна и вътрешна отчетност), и в някои други системи. За експерименти решихме да започнем с безплатната версия на SonarQube. И така, да преминем към нашия случай.

Процес на внедряване

Имаме:

• автоматично изграждане на системата в TeamCity;
• настроен е процесът на качване на кода чрез MergeRequest от feature-клон в master-клон в GitLab (процес на разработка съгласно GitHub Flow);
• SonarQube, настроен да анализира кода за системата ДПО по график.

Нашата цел: внедряване на автоматичен анализ на кода в CI/CD процесите на ДПО.

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

Т.е. целевата картина е следната: щом разработчикът качи промени в feature-клона, автоматично се стартира проверка за наличие на нови грешки в кода. Ако няма грешки, се разрешава приемането на промените, иначе ще трябва да се поправят грешките. Вече в началния етап успяхме да идентифицираме определено количество грешки в кода. Системата има много гъвкави настройки: може да се конфигурира така, че да работи по конкретни задачи на разработчиците, за всяка система и стил на програмиране.

Настройка на QualityGate в SonarQube

Анализ QualityGate е нещо, което прочетохме в дълбините на интернет. Първоначално използвахме друг подход, по-сложен и от някаква страна не съвсем правилен. Първо два пъти стартирахме сканиране през SonarQube: сканирахме feature клон и клона, в който искахме да слеем feature клона, а след това сравнявахме броя на грешките. Този метод не беше стабилен и не винаги даваше правилни резултати. И след това научихме, че вместо двойно стартиране на SonarQube, можем да настроим лимит на допустимите грешки (QualityGate) и да анализираме само клона, който качваме и сравняваме.

Все още използваме доста примитивна проверка на кода. Следва да отбележим, че SonarQube не е съвместим с някои езици за програмиране, включително Delphi. В момента анализираме само PLSql код за нашата система.

Работи така:

• Анализираме само PL/SQL код за нашия проект.
• QualityGate в SonarQube е настроен така, че броят на грешките да не се увеличава с всеки комит.
• Броят на грешките при първото стартиране беше 229. Ако броят на грешките при комита нараства, то сливането не се разрешава.
• След поправката на грешките QualityGate може да бъде преподредено.
• Също така, могат да се добавят нови елементи за анализ, например, покритие на кода с тестове и т.н.

Схема на работа:

В коментарите от работата на скрипта се вижда, че броят на грешките в feature клона не се е увеличил. Значи всичко е наред.

Достъпна е бутонът Merge.

В коментарите от работата на скрипта се вижда, че броят на грешките в feature клона е станал по-висок от допустимото. Значи всичко е лошо.

Бутонът Merge е червен. В момента няма забрана за качване на промени с грешен код, но това се прави по усмотрение на отговорния разработчик. В бъдеще може да се забрани внасянето на такива комити в основния клон.

Самостоятелна работа върху грешките

Следва да проверите всички открити от системата грешки, защото SonarQube анализира по собствените си строги стандарти. Това, което той счита за грешка, в нашия код може да не е такова. Затова е необходимо да проверим и да отбележим дали наистина е грешка, или нещо, което не е нужно да се коригира при нашите условия. Така намаляваме броя на грешките. С течение на времето системата ще се научи да разбира тези нюанси.

До какво стигнахме

Нашата цел беше да разберем дали в нашия случай е целесъобразно да се автоматизира проверката на кода. И резултатът оправда очакванията. SonarQube ни позволява да работим с необходимите за нас езици, извършва доста компетентен анализ и има потенциал да се обучава на съвети от разработчиците. В цялост, сме доволни от първоначалния си опит с SonarQube и планираме да се развиваме в тази посока нататък. Очакваме, че в бъдеще ще можем да спестим повече време и усилия при проверката на кода и да я направим по-качествена, като елиминираме човешкия фактор. Може би, по време на този процес, ще открием недостатъци в платформата или пък отново ще се уверим, че това е страхотен инструмент с голям потенциал.

В тази обзорна статия разказахме за нашето запознанство със статичния анализатор SonarQube. Ако имате въпроси, моля пишете в коментарите. Ако темата ви интересува, в новата публикация вече по-подробно ще опишем как да настроим всичко правилно и как да напишем код, за да направим подобна проверка.

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

Източник: habr.com