Сервис анализа качества кода
Сервис анализа качества кода (услуга 1.27) обеспечивает следующую функциональность:
-
непрерывный анализ и измерение качества кода, поддержка разработчиков при обнаружении недостатков созданного или повторно использованного кода за счет:
- возможности интеграции с Сервисом управления сборкой ПО для встраивания анализа качества кода в конвейер сборки дистрибутива;
- наличия встроенных правил и стандартов кодирования, обеспечивающих надежность и безопасность кода, правил оформления и документирования исходного кода, как минимум на языке Java;
-
выявление показателей и предоставление отчетности по метрикам кода:
- степень отклонений от стандартов кодирования, обеспечивающих надежность и безопасность кода;
- отклонения от стандартов оформления и документирования кода;
- выявление показателей и предоставление отчетности по метрикам кода:
- степень покрытия кода модульными тестами;
- наличие и уровень дефектов, выявленных тестами;
-
выявление показателей и предоставление отчетности по метрике дублирования кода;
-
выявления показателей и предоставление отчетности по метрике поддерживаемости кода и объему технического долга (показатель исправления ранее выявленных дефектов);
-
выявление показателей и предоставление отчетности по метрике структурного качества и сложности программного кода (показатель количества возможных путей исполнения кода);
-
установка контрольных точек просмотра мест возникновения выявленных дефектов в исходном коде, предоставление описания причины возникновения дефекта;
-
настройка допустимого уровня дефектов по метрикам покрытия модульными тестами и критичности дефектов, выявленных модульными тестами, степени дублирования кода, размеру технического долга;
-
многопользовательский режим работы с проектом.
Сервис анализа качества кода (услуга 1.27) основан на SonarQube версии 7.0 и выше и предназначен для обеспечения непрерывного анализа и измерения качества кода.
SonarSource не предоставляет конкретных рекомендаций по настройке обратного прокси-сервера (балансировки нагрузки) или конкретной конфигурации. Прокси-сервер должен обеспечивать возможность балансировки HTTP-запросов (нагрузки) между узлами приложения в кластере SonarQube.
Настройка анализа PR для Multibranch Pipeline
Для Multibranch Pipeline сборка осуществляется без параметров. Следующие параметры необходимо задать из переменных окружения:
sonar.branch.name;sonar.branch.target.
В таблице ниже указаны переменные окружения.
| Переменная | Описание |
|---|---|
BRANCH_NAME | Для Multibranch Pipeline проекта эта переменная окружения имеет значение имени ветки, из которой осуществляется сборка. Примером использования может быть условие деплоя на стенд только из ветки master. Не используется при сборке PR |
CHANGE_ID | Соответствует идентификатору PR, в случае сборки по ветке не имеет значения |
CHANGE_URL | Ссылка на страницу PR. В случае сборки по ветке не имеет значения |
CHANGE_TITLE | Наименование PR. В случае сборки по ветке не имеет значения |
CHANGE_AUTHOR | Логин автора PR. В случае сборки по ветке не имеет значения |
CHANGE_AUTHOR_DISPLAY_NAME | Выводимое имя автора PR. В случае сборки по ветке не имеет значения |
CHANGE_AUTHOR_EMAIL | Email автора PR. В случае сборки по ветке не имеет значения |
CHANGE_TARGET | Целевая ветка, в которую будут влиты изменения PR. В случае сборки по ветке не имеет значения |
CHANGE_BRANCH | Исходная ветка PR, из которой вливаются изменения в целевую. В случае сборки по ветке не имеет значения |
Настройка анализа PR для Groovy задачи
Настройка cервиса версионного контроля исходного кода и конфигураций позволяет организовать интеграцию с cервисом анализа качества кода для дальнейшего выполнения анализа кода.
Минимальная конфигурация Сервиса обеспечивает:
- таймаут на формирование HTTP-запроса со стороны клиента после установления соединения (параметр
timeout http-request) — 120 секунд; - таймаут на установление соединения с сервером Gitlab — 10 секунд;
- таймаут на ожидание ответа от сервера Gitlab (параметр
timeout server) — 3 минуты; - максимальное количество соединений (параметр
maxconn, определяет максимально возможное количество соединений со стороны Потребителей, суммарный показатель по всем сервисам Works) — не более 50 000. Может уменьшаться в зависимости от ресурсов, потребляемых соединениями со стороны Потребителя.