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