Получить инструмент контроля качества разрабатываемого кода. Снизить количество явных багов, уязвимостей и запахов кода (code smell). А также не допустить попадание подобного кода в продакшн среду.
После недолгого изучения просторов интернета мы остановили свой выбор на статическом анализаторе кода SonarQube (Community edition) как на наиболее популярном инструменте для решения нашей задачи.
SonarQube – это система с открытым исходным кодом, которая сканирует ваш исходный код в поисках потенциальных ошибок, уязвимостей и проблем с поддержкой, а затем представляет результаты в отчете, который позволит вам выявить потенциальные проблемы в приложении.
Система состоит из двух компонентов: анализатор, который локально собирает проект и проводит анализ и сервер, который собирает результаты анализа, хранит статистику, историю и позволяет настраивать параметры и правила проведения анализа.
Для себя мы выработали следующую схему реализации:
Что анализируем:
Если любой из показателей больше 0, то запрос на слияние блокируется до момента устранения всех замечаний анализатора. В случае ошибок в ночной проверке блокируется предстоящая поставка на прод.
В нашем случае анализатор SonarQube расположен на выделенной виртуальной машине. Репозиторий нашего проекта расположен на платформе GitLab. Интеграция построена средствами CI/CD системы GitLab.
Мы используем локальный сервер SonarQube. Скачать его образ можно по данной ссылке .
Процесс развертывания и настройки сервера описан в официальной инструкции в зависимости от конфигурации вашего окружения.
Далее переходим к добавлению нашего проекта:
Генерируем токен. Его необходимо сохранить для дальнейшей настройки анализа
Для анализа можно использовать настройки по умолчанию либо задать свои.
Мы используем следующие настройки.
Также можно настроить профили анализа в разделе “Quality Profiles” исходя из ваших требований и языков программирования.
Первым делом потребуется служба GitLab Runner, которую можно разместить на той же виртуальной машине, что и анализатор. Подробно останавливаться на настройке службы мы не будем. Все необходимое есть в этой инструкции.
Далее необходим конфигурационный файл для нашего проекта. В нем будут описаны все шаги так называемого pipeline.
Конфигурационный файл нашего проекта выглядит следующим образом:
stage – этот параметр описывает название этапа.
before_script – описывает действие перед выполнением основной задачи (необязательно).
cache – устанавливает набор ключей и локальных путей (внутри проекта, который собираем) для хранения этого набора при переходе между этапами.
tags – набор тегов по которым раннер может понять умеет ли он выполнять данную задачу или нет
script – основной скрипт который будет выполнен раннером. Это может быть как файл скрипта внутри проекта который собираем, так и просто строка скрипта.
after_script – действие после выполнения основного скрипта (необязательно).
only – определяет, в каких случаях задача будет добавлена в пайплайн.
Этап run-sonar запускает анализ кода скриптом sonar_run.bat
Проверка нужна для того, чтобы не запускать анализ лишний раз, если это не запрос на слияние с основной веткой разработки. Здесь в качестве sonar.login нужно указать токен, который был сгенерирован на этапе настройки проекта в SonarQube.
Подробнее про настройки конфигурационного файла можно почитать здесь
Затем необходимо заблокировать запрос на слияние если любой из этапов пайплайна выполнен с ошибкой.
Настроить это можно следующим образом:
На этом настройка GitLab закончена. В итоге при срабатывании pipeline мы получим результат его выполнения в виде замечания к запросу на слияние.
Пример успешно выполненного анализа:
Пример анализа с ошибками:
Благодаря внедрению автоматического анализа кода через SonarQube мы снизили количество ошибок и багов, а код нашего проекта стал более чистым. Блокировка запроса на слияние не дает возможности разработчику слить заведомо неисправный функционал в основную ветку разработки. Тем самым мы снизили затраты на код ревью и упростили работу QA инженеру.