1. Обзор
В этой статье мы рассмотрим статический анализ исходного кода с помощью SonarQube — платформы с открытым исходным кодом для обеспечения качества кода.
Давайте начнем с основного вопроса — зачем вообще анализировать исходный код? Проще говоря, для обеспечения качества, надежности и ремонтопригодности в течение всего срока службы проекта; плохо написанная кодовая база всегда обходится дороже.
Хорошо, теперь давайте начнем, загрузив последнюю LTS-версию SonarQube со страницы загрузки и настроив наш локальный сервер, как описано в этом кратком руководстве .
2. Анализ исходного кода
Теперь, когда мы вошли в систему, нам необходимо создать токен, указав имя — это может быть наше имя пользователя или любое другое имя по выбору и нажать кнопку «Создать» .
Мы будем использовать токен позже при анализе нашего проекта(ов). Также нам необходимо выбрать основной язык (Java) и технологию сборки проекта (Maven).
Давайте определим плагин в pom.xml :
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.sonarsource.scanner.maven</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>3.4.0.905</version>
</plugin>
</plugins>
</pluginManagement>
</build>
Последняя версия плагина доступна здесь . Теперь нам нужно выполнить эту команду из корня каталога нашего проекта, чтобы отсканировать его:
mvn sonar:sonar -Dsonar.host.url=http://localhost:9000
-Dsonar.login=the-generated-token
Нам нужно заменить сгенерированный токен на токен сверху.
Проект, который мы использовали в этой статье, доступен здесь .
Мы указали URL-адрес хоста сервера SonarQube и логин (сгенерированный токен) в качестве параметров для плагина Maven.
После выполнения команды результаты будут доступны на панели Projects — по адресу http://localhost:9000 .
Есть и другие параметры, которые мы можем передать плагину Maven или даже установить из веб-интерфейса; сонар.хост. url, sonar.projectKey и sonar.sources являются обязательными, а другие необязательными.
Другие параметры анализа и их значения по умолчанию находятся здесь . Также обратите внимание, что у каждого языкового плагина есть правила для анализа совместимого исходного кода.
3. Результат анализа
Теперь, когда мы проанализировали наш первый проект, мы можем перейти в веб-интерфейс по адресу http://localhost:9000 и обновить страницу.
Там мы увидим сводку отчета:
Обнаруженные проблемы могут быть ошибкой, уязвимостью, запахом кода, покрытием или дублированием. Каждая категория имеет соответствующее количество проблем или процентное значение.
Кроме того, проблемы могут иметь один из пяти различных уровней серьезности: блокирующий, критический, серьезный, незначительный и информационный. Прямо перед названием проекта находится значок, который отображает статус Quality Gate — пройдено (зеленый) или не выполнено (красный).
Нажав на название проекта, мы перейдем на специальную панель инструментов, где мы сможем более подробно изучить проблемы, связанные с проектом.
Мы можем видеть код проекта, активность и выполнять административные задачи с панели управления проекта — каждая из них доступна на отдельной вкладке.
Несмотря на наличие глобальной вкладки «Проблемы», вкладка « Проблемы » на панели управления проекта отображает проблемы, характерные только для соответствующего проекта:
На вкладке «Проблемы» всегда отображаются категория, уровень серьезности, теги и расчетные усилия (относительно времени), которые потребуются для устранения проблемы.
На вкладке «Проблемы» можно назначить проблему другому пользователю, прокомментировать ее и изменить уровень серьезности. Нажав на саму проблему, вы увидите более подробную информацию о проблеме.
Вкладка «Выпуск» содержит сложные фильтры слева. Они хороши для выявления проблем. Итак, как узнать, достаточно ли работоспособна кодовая база для развертывания в рабочей среде? Вот для чего нужны Ворота Качества.
4. Ворота качества SonarQube
В этом разделе мы рассмотрим ключевую функцию SonarQube — Quality Gate. Затем мы увидим пример того, как настроить пользовательский.
4.1. Что такое ворота качества?
Ворота качества — это набор условий, которым должен соответствовать проект, прежде чем он сможет претендовать на выпуск в производство. Он отвечает на один вопрос: могу ли я отправить свой код в производство в его текущем состоянии или нет?
Обеспечение качества «нового» кода при исправлении существующего — один из хороших способов поддерживать хорошую кодовую базу с течением времени. Quality Gate упрощает настройку правил проверки каждого нового кода, добавляемого в кодовую базу при последующем анализе .
Условия, установленные в Quality Gate, по-прежнему влияют на неизмененные сегменты кода. Если мы сможем предотвратить возникновение новых проблем, со временем мы устраним все проблемы.
Такой подход сравним с фиксацией утечки воды из источника. Это подводит нас к особому термину – Период утечки. Это период между двумя анализами/версиями проекта .
Если мы повторно запустим анализ в том же проекте, на вкладке обзора панели управления проекта будут показаны результаты за период утечки:
В веб-интерфейсе на вкладке Quality Gates мы можем получить доступ ко всем определенным критериям качества. По умолчанию SonarQube был предустановлен на сервере.
Конфигурация по умолчанию для способа SonarQube помечает код как неудавшийся, если:
- охват нового кода составляет менее 80%
- процент повторяющихся строк в новом коде больше 3
- ремонтопригодность, надежность или рейтинг безопасности хуже, чем А
С этим пониманием мы можем создать настраиваемые Ворота Качества.
4.2. Добавление пользовательских ворот качества
Сначала нам нужно щелкнуть вкладку « Качественные ворота », а затем нажать кнопку « Создать » , которая находится в левой части страницы. Нам нужно дать ему имя — foreach .
Теперь мы можем установить нужные условия:
В раскрывающемся списке « Добавить условие » выберите Blocker Issues ; он сразу появится в списке условий.
В качестве оператора укажем больше чем , установим ноль (0) для столбца Error и отметим столбец Over Leak Period : ``
Затем мы нажмем кнопку « Добавить » , чтобы изменения вступили в силу . Давайте добавим еще одно условие, следуя той же процедуре, что и выше.
Мы выберем проблемы из раскрывающегося списка « Добавить условие ` » и отметим столбец Over Leak Period .`
Значение столбца « Оператор » будет установлено на « меньше чем» , и мы добавим единицу (1) в качестве значения столбца « Ошибка ». Это означает , что если количество проблем в добавленном новом коде меньше 1, пометить контроль качества как не пройденный .
Я знаю, что это не имеет технического смысла, но давайте использовать его для обучения. Не забудьте нажать кнопку « Добавить », чтобы сохранить правило.
И последний шаг: нам нужно прикрепить проект к нашим пользовательским воротам качества. Мы можем сделать это, прокрутив страницу вниз до раздела «Проекты».
Там нам нужно нажать «Все», а затем отметить наш проект по выбору. Мы также можем установить его в качестве шлюза качества по умолчанию в правом верхнем углу страницы.
Мы снова просканируем исходный код проекта, как мы это делали раньше с помощью команды Maven. Когда это будет сделано, мы перейдем на вкладку проектов и обновим.
На этот раз проект не будет соответствовать критериям Quality Gate и потерпит неудачу. Почему? Поскольку в одном из наших правил мы указали, что он должен дать сбой, если нет новых проблем.
Давайте вернемся на вкладку Quality Gates и изменим условие для проблем на больше, чем . Нам нужно нажать кнопку обновления, чтобы применить это изменение.
На этот раз пройдет новое сканирование исходного кода.
5. Интеграция SonarQube в CI
Сделать SonarQube частью процесса непрерывной интеграции вполне возможно. Это автоматически приведет к сбою сборки, если анализ кода не удовлетворит условию Quality Gate.
Для этого мы будем использовать SonarCloud , который является облачной версией сервера SonaQube. Мы можем создать учетную запись здесь .
В разделе «Моя учетная запись» > «Организации» мы можем увидеть ключ организации, и обычно он имеет вид xxxx-github или xxxx-bitbucket .
Также из My Account > Security мы можем сгенерировать токен, как мы это делали в локальном экземпляре сервера. Запишите токен и ключ организации для последующего использования.
В этой статье мы будем использовать Travis CI и создадим здесь учетную запись с существующим профилем Github. Он загрузит все наши проекты, и мы можем включить любой из них, чтобы активировать на нем Travis CI.
Нам нужно добавить токен, который мы сгенерировали в SonarCloud, в переменные среды Travis. Мы можем сделать это, нажав на проект, который мы активировали для CI.
Затем мы нажмем «Дополнительные параметры»> «Настройки», а затем прокрутим вниз до «Переменные среды»:
Мы добавим новую запись с именем SONAR_TOKEN и будем использовать токен, сгенерированный в SonarCloud, в качестве значения. Travis CI зашифрует и скроет его от всеобщего обозрения:
Наконец, нам нужно добавить файл .travis.yml в корень нашего проекта со следующим содержимым:
language: java
sudo: false
install: true
addons:
sonarcloud:
organization: "your_organization_key"
token:
secure: "$SONAR_TOKEN"
jdk:
- oraclejdk8
script:
- mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent package sonar:sonar
cache:
directories:
- '$HOME/.m2/repository'
- '$HOME/.sonar/cache'
Не забудьте заменить ключ организации на ключ организации, описанный выше. Фиксация нового кода и отправка в репозиторий Github вызовет сборку Travis CI и, в свою очередь, также активирует сканирование сонара.
6. Заключение
В этом руководстве мы рассмотрели, как настроить сервер SonarQube локально и как использовать Quality Gate для определения критериев пригодности проекта для выпуска в производство.
Документация SonarQube содержит больше информации о других аспектах платформы.