Ми хочемо поділитися досвідом впровадження платформи для безперервного аналізу та вимірювання якості коду 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