====== Как внедрить SonarQube в проект ====== ===== Цель ===== Получить инструмент контроля качества разрабатываемого кода. Снизить количество явных багов, уязвимостей и запахов кода (code smell). А также не допустить попадание подобного кода в продакшн среду. ===== Наш выбор ===== После недолгого изучения просторов интернета мы остановили свой выбор на статическом анализаторе кода SonarQube (Community edition) как на наиболее популярном инструменте для решения нашей задачи. ===== Что такое SonarQube? ===== SonarQube – это система с открытым исходным кодом, которая сканирует ваш исходный код в поисках потенциальных ошибок, уязвимостей и проблем с поддержкой, а затем представляет результаты в отчете, который позволит вам выявить потенциальные проблемы в приложении. Система состоит из двух компонентов: анализатор, который локально собирает проект и проводит анализ и сервер, который собирает результаты анализа, хранит статистику, историю и позволяет настраивать параметры и правила проведения анализа. ===== Схема реализации ===== Для себя мы выработали следующую схему реализации: * каждый запрос за слияние (pull request, merge request) с основной веткой разработки обязательно должен быть проверен через SonarQube. * запуск анализа основной ветки разработки каждую ночь для исключения возможных отклонений/ошибок при анализе каждого запроса на слияние. Что анализируем: * количество запахов кода * количество явных багов * количество уязвимостей Если любой из показателей больше 0, то запрос на слияние блокируется до момента устранения всех замечаний анализатора. В случае ошибок в ночной проверке блокируется предстоящая поставка на прод. ===== Пример реализации ===== В нашем случае анализатор SonarQube расположен на выделенной виртуальной машине. Репозиторий нашего проекта расположен на платформе [[https://about.gitlab.com/|GitLab]]. Интеграция построена средствами CI/CD системы GitLab. ==== Настройка SonarQube ==== Мы используем локальный сервер SonarQube. Скачать его образ можно [[https://www.sonarqube.org/downloads/|по данной ссылке]] . Процесс развертывания и настройки сервера описан в официальной [[https://docs.sonarqube.org/latest/setup/install-server/|инструкции]] в зависимости от конфигурации вашего окружения. Далее переходим к добавлению нашего проекта: {{https://fatalex.cifro.net/lib/plugins/ckgedit/fckeditor/userfiles/image/devops/proekt-dobavlenie.png.webp?nolink&1328x415|article-image}} Генерируем токен. Его необходимо сохранить для дальнейшей настройки анализа {{https://fatalex.cifro.net/lib/plugins/ckgedit/fckeditor/userfiles/image/devops/token.png.webp?nolink&1335x508|article-image}} Для анализа можно использовать настройки по умолчанию либо задать свои. Мы используем следующие настройки. {{https://fatalex.cifro.net/lib/plugins/ckgedit/fckeditor/userfiles/image/devops/nastroyki-kachestva.png.webp?nolink&1374x923|article-image}} Также можно настроить профили анализа в разделе “Quality Profiles” исходя из ваших требований и языков программирования. {{https://fatalex.cifro.net/lib/plugins/ckgedit/fckeditor/userfiles/image/devops/profily-kachestva.png.webp?nolink&943x892|article-image}} ==== Настройка GitLab ==== Первым делом потребуется служба GitLab Runner, которую можно разместить на той же виртуальной машине, что и анализатор. Подробно останавливаться на настройке службы мы не будем. Все необходимое есть в этой [[https://docs.gitlab.com/runner/install/|инструкции]]. Далее необходим конфигурационный файл для нашего проекта. В нем будут описаны все шаги так называемого pipeline. Конфигурационный файл нашего проекта выглядит следующим образом: {{https://fatalex.cifro.net/lib/plugins/ckgedit/fckeditor/userfiles/image/devops/konfig-fayl.png.webp?nolink&866x403|article-image}} **stage** – этот параметр описывает название этапа. **before_script** – описывает действие перед выполнением основной задачи (необязательно). **cache** – устанавливает набор ключей и локальных путей (внутри проекта, который собираем) для хранения этого набора при переходе между этапами. **tags** – набор тегов по которым раннер может понять умеет ли он выполнять данную задачу или нет **script** – основной скрипт который будет выполнен раннером. Это может быть как файл скрипта внутри проекта который собираем, так и просто строка скрипта. **after_script **– действие после выполнения основного скрипта (необязательно). **only** – определяет, в каких случаях задача будет добавлена в пайплайн. Этап **run-sonar** запускает анализ кода скриптом **sonar_run.bat** {{https://fatalex.cifro.net/lib/plugins/ckgedit/fckeditor/userfiles/image/devops/script-sonara.png.webp?nolink&1178x335|article-image}} Проверка нужна для того, чтобы не запускать анализ лишний раз, если это не запрос на слияние с основной веткой разработки. Здесь в качестве **sonar.login** нужно указать токен, который был сгенерирован на этапе настройки проекта в SonarQube. Подробнее про настройки конфигурационного файла можно почитать [[https://docs.gitlab.com/ee/ci/quick_start/|здесь]] Затем необходимо заблокировать запрос на слияние если любой из этапов пайплайна выполнен с ошибкой. Настроить это можно следующим образом: - Зайти в общие настройки репозитория {{https://fatalex.cifro.net/lib/plugins/ckgedit/fckeditor/userfiles/image/devops/screenshot_18.png.webp?nolink&336x360|article-image}} - Развернуть настройки запросов на слияние и указать следующие пункты {{https://fatalex.cifro.net/lib/plugins/ckgedit/fckeditor/userfiles/image/devops/mr-yfcnhjy.png.webp?nolink&881x274|article-image}} На этом настройка GitLab закончена. В итоге при срабатывании pipeline мы получим результат его выполнения в виде замечания к запросу на слияние. Пример успешно выполненного анализа: {{https://fatalex.cifro.net/lib/plugins/ckgedit/fckeditor/userfiles/image/devops/analiz-uspeh.png.webp?nolink&973x491|article-image}} Пример анализа с ошибками: {{https://fatalex.cifro.net/lib/plugins/ckgedit/fckeditor/userfiles/image/devops/analiz-oshib1.png.webp?nolink&979x531|article-image}} {{https://fatalex.cifro.net/lib/plugins/ckgedit/fckeditor/userfiles/image/devops/analiz-oshib2.png.webp?nolink&975x524|article-image}} ===== Итог ===== Благодаря внедрению автоматического анализа кода через SonarQube мы снизили количество ошибок и багов, а код нашего проекта стал более чистым. Блокировка запроса на слияние не дает возможности разработчику слить заведомо неисправный функционал в основную ветку разработки. Тем самым мы снизили затраты на код ревью и упростили работу QA инженеру.