Как внедрить SonarQube в проект

Получить инструмент контроля качества разрабатываемого кода. Снизить количество явных багов, уязвимостей и запахов кода (code smell). А также не допустить попадание подобного кода в продакшн среду.

После недолгого изучения просторов интернета мы остановили свой выбор на статическом анализаторе кода SonarQube (Community edition) как на наиболее популярном инструменте для решения нашей задачи.

SonarQube – это система с открытым исходным кодом, которая сканирует ваш исходный код в поисках потенциальных ошибок, уязвимостей и проблем с поддержкой, а затем представляет результаты в отчете, который позволит вам выявить потенциальные проблемы в приложении.

Система состоит из двух компонентов: анализатор, который локально собирает проект и проводит анализ и сервер, который собирает результаты анализа, хранит статистику, историю и позволяет настраивать параметры и правила проведения анализа.

Для себя мы выработали следующую схему реализации:

• каждый запрос за слияние (pull request, merge request) с основной веткой разработки обязательно должен быть проверен через 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.

Подробнее про настройки конфигурационного файла можно почитать здесь

Затем необходимо заблокировать запрос на слияние если любой из этапов пайплайна выполнен с ошибкой.

Настроить это можно следующим образом:

1. Зайти в общие настройки репозитория

1. Развернуть настройки запросов на слияние и указать следующие пункты

На этом настройка GitLab закончена. В итоге при срабатывании pipeline мы получим результат его выполнения в виде замечания к запросу на слияние.

Пример успешно выполненного анализа:

Пример анализа с ошибками:

Благодаря внедрению автоматического анализа кода через SonarQube мы снизили количество ошибок и багов, а код нашего проекта стал более чистым. Блокировка запроса на слияние не дает возможности разработчику слить заведомо неисправный функционал в основную ветку разработки. Тем самым мы снизили затраты на код ревью и упростили работу QA инженеру.