Мы хотим поделиться опытом внедрения платформы для непрерывного анализа и измерения качества кода 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. Если у вас есть вопросы, пишите, пожалуйста, в комментариях. Если вам интересна эта тема, в новой публикации мы уже подробнее опишем, как правильно все настроить и написать код, чтобы делать подобную проверку.

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