Мы жадаем падзяліцца досведам укаранення платформы для бесперапыннага аналізу і вымярэнні якасці кода SonarQube у існыя працэсы распрацоўкі сістэмы ДПО (дадатак да сістэмы дэпазітарна-клірынгавага ўліку «Аламеда») Нацыянальнага разліковага дэпазітарыя.
Нацыянальны разліковы дэпазітарый (група кампаній "Маскоўская біржа") з'яўляецца адной з ключавых кампаній фінансавай інфраструктуры, захоўвае і ўлічвае каштоўныя паперы расійскіх і замежных эмітэнтаў на суму больш за 50 трлн руб. Які расце аб'ём праводжаных сістэмай аперацый, а гэтак жа бесперапыннае нарошчванне функцыяналу патрабуюць падтрыманні высокай якасці зыходнага кода сістэм. Адным з інструментаў для дасягнення гэтай мэты з'яўляецца статычны аналізатар SonarQube. У гэтым артыкуле мы апішам паспяховы досвед бясшвоўнага ўкаранення статычнага аналізатара SonarQube у існыя працэсы распрацоўкі нашага аддзела.
Коратка аб аддзеле
У нашай кампетэнцыі наступныя модулі: выплаты кліентам НРД, электронны дакументаабарот (ЭДА), апрацоўка паведамленняў гандлёвага рэпазітара (рэгістрацыя пазабіржавых здзелак), каналы электроннага ўзаемадзеяння паміж кліентамі і НРД і многае іншае. Увогуле, вялікі пласт працы над тэхнічным бокам аперацыйнай дзейнасці. Працуем мы на аснове заявак. Заяўкі аперацыністаў апрацоўваецца аналітыкамі: яны збіраюць патрабаванні заказчыка і прадстаўляе нам сваё бачанне таго, як гэта павінна легчы ў праграму. Далей стандартная схема: распрацоўка кода - тэсціраванне - доследная эксплуатацыя - пастаўка кода на прадуктыўны контур непасрэднаму заказчыку.
Чаму менавіта SonarQube?
Гэта першы досвед нашага аддзела па ўкараненні платформы для кантролю якасці кода - раней мы рабілі гэта ўручную, праводзілі толькі code review. Але які расце аб'ём прац патрабуе аўтаматызацыі дадзенага працэсу. Акрамя гэтага, у складзе каманды ёсць і неспрактыкаваныя супрацоўнікі, якія не зусім знаёмыя з унутранымі рэгламентамі распрацоўкі і схільныя дапускаць больш памылак. Для кантролю якасці кода было вырашана ўкараняць статычны аналізатар. Бо SonarQube ужо выкарыстоўваўся ў некаторых сістэмах НРД, доўга выбіраць не прыйшлося. Раней калегі з іншых падраздзяленняў аналізавалі з яго дапамогай код мікрасэрвісаў у сістэме "Аламеда" (уласная сістэма дэпазітарна-клірынгавага ўліку НРД), у ЦФТ (інфармацыйная сістэма для вядзення бух. ўліку, балансу, падрыхтоўкі абавязковай і ўнутранай справаздачнасці), у некаторых іншых сістэмах . Для эксперыментаў мы вырашылі пачаць з бясплатнай версіі SonarQube. Дык вось, пяройдзем да нашага кейсу.
Працэс укаранення
У нас ёсць:
- аўтаматычная зборка сістэмы ў TeamCity;
- настроены працэс залівання кода праз MergeRequest з feature-галінкі ў master-галінку ў GitLab (працэс распрацоўкі паводле GitHub Flow);
- SonarQube, наладжаны на аналіз кода для сістэмы ДПО па раскладзе.
Наша мэта: укараніць аўтаматычны аналіз кода ў CI/CD працэсы ДПО.
Трэба настроіць: працэс аўтаматычнай праверкі кода статычным аналізатарам пры кожным MergeRequest'e у асноўную галіну.
Г.зн. мэтавая карціна наступная: як толькі распрацоўшчык залівае змены ў feature-галінку, запускаецца аўтаматычная праверка на наяўнасць новых памылак у кодзе. Калі памылак няма, то дазваляецца прыняцце змен, інакш прыйдзецца правіць памылкі. Ужо на пачатковым этапе мы змаглі выявіць пэўную колькасць памылак у кодзе. У сістэмы вельмі гнуткія налады: яе можна наладжваць такім чынам, каб яна працавала пад канкрэтныя задачы распрацоўшчыкаў, пад кожную сістэму і стыль праграмавання.
Настройка QualityGate ў SonarQube
Аналіз QualityGate - гэта рэч, якую мы адымалі ў нетрах інтэрнэту. Першапачаткова мы выкарыстоўвалі іншы падыход, больш складаны і з нейкага боку не зусім правільны. Спачатку мы двойчы запускалі сканаванне праз SonarQube: сканавалі feature-галінку і галінку, куды збіраліся ўліваць feature-галінку, а затым параўноўвалі колькасць памылак. Гэты метад не вызначаўся стабільнасцю і не заўсёды выдаваў правільны вынік. А затым мы даведаліся, што можна замест падвойнага прагону SonarQube, усталяваць ліміт на колькасць дапушчаных памылак (QualityGate) і аналізаваць толькі тую галінку, якую ты заліваеш і параўноўваеш.
Пакуль што мы выкарыстоўваем даволі прымітыўную праверку кода. Варта адзначыць, што SonarQube несумяшчальны з некаторымі мовамі праграмавання, у тым ліку з Delphi. На дадзены момант для нашай сістэмы аналізуем толькі PLSql код.
Працуе гэта так:
- Мы аналізуем для нашага праекту толькі PL/SQL код.
- У SonarQube наладжаны QualityGate такім чынам, каб колькасць памылак не дадавалася з коммітам.
- Колькасць памылак пры першым запуску ў нас выйшла 229. Калі памылак пры каментары становіцца больш, то merge не дазваляецца.
- Далей пры ўмове выпраўлення памылак можна будзе пераналаджваць QualityGate.
- Таксама можна дадаваць новыя пункты для аналізу, напрыклад, пакрыццё кода тэстамі і т.д.
Схема працы:
У каментарах працы скрыпту бачна, што колькасць памылак у feature-галінцы не павялічылася. Значыць усё ОК.
Становіцца даступная кнопка Merge.
У каментарах працы скрыпту відаць, што колькасць памылак у feature-галінцы стала больш дапушчальнай. Значыць усё Дрэнна.
Кнопка Merge чырвоная. На дадзены момант няма забароны на тое каб заліць змены па памылковым кодзе, але гэта робіцца на меркаванне адказнага распрацоўніка. У далейшым можна забараніць уносіць такія коміты ў асноўную галінку.
Самастойная праца над памылкамі
Далей неабходна праверыць усе выяўленыя сістэмай памылкі, таму што SonarQube аналізуе па сваіх строгіх стандартах. Што ён лічыць памылкай, рэальна ў нашым кодзе можа такім не зьяўляцца. Таму трэба праверыць і адзначыць, ці сапраўды гэта памылка, ці тое, што кіраваць у нашых умовах неабходнасці няма. Такім чынам мы скарачаем колькасць памылак. З часам сістэма навучыцца разумець гэтыя нюансы.
Да чаго мы прыйшлі
Нашай мэтай было зразумець, ці мэтазгодна ў нашым выпадку пераводзіць праверку кода на аўтаматызацыю. І вынік апраўдаў чаканні. SonarQube дазваляе нам працаваць з патрэбнымі нам мовамі, робіць даволі пісьменны аналіз і мае патэнцыял вучыцца на падказках распрацоўшчыкаў. У цэлым, мы задаволены нашым першым вопытам выкарыстання SonarQube і плануем развівацца ў гэтым напрамку далей. Чакаем, што ў будучыні мы зможам эканоміць больш часу і сіл на праверку кода і зрабіць яе больш якаснай, устараніўшы чалавечы фактар. Магчыма, падчас мы выявім недахопы платформы ці, наадварот, пераканаемся яшчэ раз, што гэта крутая рэч з вялікім патэнцыялам.
У гэтым аглядным артыкуле мы распавялі аб нашым знаёмстве са статычным аналізатарам SonarQube. Калі ў вас ёсць пытанні, пішыце, калі ласка, у каментарах. Калі вам цікавая гэтая тэма, у новай публікацыі мы ўжо падрабязней апішам, як правільна ўсё наладзіць і напісаць код, каб рабіць падобную праверку.
Аўтар тэксту:
Крыніца: habr.com