Статический анализ кода — это важная составляющая всех современных проектов. Еще более значимым является его правильное применение. Мы решили организовать регулярную проверку некоторых открытых проектов, чтобы увидеть эффект от частого прогона анализатора. Мы используем анализатор PVS-Studio для проверки проектов, а просматривать результаты будем при помощи SonarQube. Так наши подписчики будут узнавать о новых интересных багах в только что написанном коде. Думаем, это будет забавно.
Почему же все-таки важна регулярная проверка проектов? Если запускать статический анализ редко, например, только перед релизом, то можно "утонуть" в большом количестве предупреждений и, просматривая их все, можно пропустить действительно важные срабатывания анализатора, указывающие на серьёзные ошибки. Если же запускать анализ регулярно, например, каждый день, то количество срабатываний будет не таким большим, и можно достаточно легко выявить действительно важные проблемы. Другая причина — это цена ошибки: чем раньше проблема будет обнаружена, тем дешевле ее устранить. Например, если запускать статический анализ только перед релизом, то к этому моменту большинство ошибок будет найдено отделом тестирования и исправлено, но такие исправления стоят дороже. То есть регулярный анализ – это единственно правильный способ использования статического анализа.
Как вы, наверное, знаете, наша команда часто публикует отчёты о проверке проектов с открытым исходным кодом. Такие статьи безусловно интересно читать, и они приносят определённую пользу и самим проверяемым проектам – мы всегда отправляем отчёт о найденных подозрительных местах разработчикам. Однако, такие единичные проверки проектов имеют те же недостатки, что и описанный выше сценарий с нерегулярной проверкой кода только перед релизом. Большой отчёт сложно воспринимать, а многие ошибки, которые можно было бы найти и исправить сразу же после их попадания в код уже оказываются исправлены на других уровнях контроля качества (например, с помощью тестов).
Поэтому мы решили попробовать новый формат работы с open source проектами – регулярная, каждодневная проверка кода одного (для начала) проекта. При этом эта проверка будет настроена так, что каждый день потребуется смотреть срабатывания анализатора только на изменившемся или вновь написанном коде — это и значительно быстрее, чем просмотр полного отчёта анализатора, и, главное – позволит очень быстро обнаружить потенциальную ошибку. Когда же мы будем встречать что-то действительно интересное, мы будем делать про это небольшие заметки или даже просто записи в Twitter.
Мы надеемся, что данный формат позволит нам как лучше популяризировать более правильную практику регулярного использования статического анализа, так и принесёт дополнительную пользу open source сообществу.
В качестве первого проекта для анализа мы решили выбрать проект Blender. Вы можете написать нам какие дополнительные проекты вы хотели бы, чтобы мы также регулярно анализировали и рассказывали про найденные в них ошибки.
Для нашей задачи самым оптимальным решением для регулярного анализа мы считаем cвязку инструментов PVS-Studio – SonarQube. Далее в статье мы расскажем про настройку выбранных инструментов: как запустить и настроить SonarQube, опишем как проанализировать проект и загрузить полученные результаты для отображения.
PVS-Studio умеет многое: анализировать, рассылать уведомления о найденных предупреждениях, фильтровать их, но также еще умеет интегрироваться в разные системы для отображения предупреждений. Чтобы не только получать результаты проверки, но и дополнительно тестировать больше режимов работы PVS-Studio, мы решили попробовать настроить отображение результатов для нашей задачи в SonarQube.
Подробности о возможностях этого приложения можно прочитать тут. Мы же приступим к развертыванию. Все данные SonarQube хранит в базе данных. Можно использовать разные базы, но рекомендованной является PostgreSQL. Сначала настроим ее.
Скачаем последнюю версию здесь. Устанавливаем базу данных, создадим базу данных для использования SonarQube. Для этого сначала создадим пользователя с именем sonar – в командной строке psql выполним следующую команду:
CREATE USER sonar WITH PASSWORD '12345';Для этой и других операций также можно использовать pgAdmin. Создадим базу с именем sonarqube при помощи команды CREATE DATABASE, в нашем случае так:
CREATE DATABASE sonarqube OWNER sonar;База данных готова, приступим к настройке SonarQube.
Скачаем и установим SonarQube. Последнюю версию можно взять отсюда. Сам дистрибутив представляет из себя архив. Распакуем архив в каталог C:\sonarqube\sonarqube-8.5.1.38104.
Отредактируем файл C:\sonarqube\sonarqube-8.5.1.38104\conf\sonar.properties. Добавим туда следующие данные для нашей созданной базы:
sonar.jdbc.username=sonar
sonar.jdbc.password=12345
sonar.jdbc.url=jdbc:postgresql://localhost/sonarqubeSonarQube увидит созданную нами базу и начнет с ней работать. Далее необходимо установить плагин для PVS-Studio. Плагин лежит в каталоге, где установлена PVS-Studio, по умолчанию это C:\Program Files (x86)\PVS-Studio. Нам нужен файл sonar-pvs-studio-plugin.jar. Скопируем его в каталог с SonarQube C:\sonarqube\sonarqube-8.5.1.38104\extensions\plugins. Также необходимо скачать плагин sonar-cxx-plugin, это можно сделать тут. На момент написания статьи это sonar-cxx-plugin-1.3.2.1853.jar. Этот плагин тоже скопируем в каталог C:\sonarqube\sonarqube-8.5.1.38104\extensions\plugins.
Теперь можно запустить SonarQube, для этого запустим C:\sonarqube\sonarqube-8.5.1.38104\bin\windows-x86-64\StartSonar.bat.
Приступим к настройке через web-интерфейс. Заходим в браузере по адресу sonarServer:9000, где sonarServer — это имя машины, где установлен SonarQube.
Профиль качества (quality profile) — это ключевой компонент SonarQube, в котором определен набор правил для кодовой базы. Плагин PVS-Studio предоставляет набор правил, соответствующий предупреждениям анализатора, в профиль качества мы можем добавить их все или отключить какие-либо правила, если в этом есть необходимость. В соответствии с настроенным профилем качества SonarQube будет отображать или не отображать предупреждения после анализа нашего кода.
Настроим Quality Profile, для этого перейдем на вкладку Quality Profiles и нажмем кнопку Create, как показано на рисунке ниже.
В появившемся окне введем имя профиля (оно может быть произвольным), в нашем случае PVS-Studio Way, и выберем язык – для нас сейчас актуален C++. После этого нажмем кнопку Create.
Потом переходим на вкладку Rules, там выбираем категорию Repository и в ней выбираем пункт PVS-Studio C++. Далее нажимаем кнопку Bulk Change и Activate In, в появившемся окне выбираем наш созданный профиль, то есть PVS-Studio Way.
SonarQube настроен и готов к работе.
Дальше настроим непосредственно анализ проекта с помощью анализатора PVS-Studio.
Скачаем исходники такой командой:
git clone https://github.com/blender/blender.gitзатем сгенерируем проектные файлы:
make.bat full nobuildсгенерируем необходимые дополнительные файлы, для этого скомпилируем проект build_windows_Full_x64_vc15_Release\INSTALL.vcxproj.
Запустим анализ командой
"c:\\Program Files (x86)\\PVS-Studio\\PVS-Studio_Cmd.exe" \
-t build_windows_Full_x64_vc15_Release\\Blender.sln \
-o blender.plog --sonarqubedata -rВ результате анализа у нас появились файлы blender.plog и sonar-project.properties, и мы можем протолкнуть результаты нашего анализа в SonarQube. Для этого надо воспользоваться утилитой sonar-scanner.
Утилиту можно скачать отсюда. По ссылке скачивается архив, его надо разархивировать, например, в нашем случае в каталог D:\sonar\sonar-scanner-4.5.0.2216-windows. Отредактируем файл D:\sonar\sonar-scanner-4.5.0.2216-windows\conf\sonar-scanner.properties, добавив в него строку:
sonar.host.url=http://sonarServer:9000Где sonarServer – имя машины, где установлен SonarQube.
Выполним следующую команду:
D:\sonar\sonar-scanner-4.5.0.2216-windows\sonar-scanner.bat \
-Dsonar.projectKey=blender -Dsonar.projectName=blender \
-Dsonar.projectVersion=1.0 \
-Dsonar.pvs-studio.reportPath=blender.plogСледует учесть, что команда вызывается из каталога с результатами анализа (blender.plog и sonar-project.properties).
Для регулярного запуска анализа на проекте все вышеописанные команды можно легко автоматизировать с помощью Continuous Integration сервера, например, Jenkins.
Регулярный анализ проекта позволяет устранять ошибки на самом раннем этапе, когда стоимость такого исправления минимальна. Мы надеемся, что такой новый формат по проверке open source проектов и рассказ об этом будет интересен нашим читателям и разбавит "обычные" статьи о проверке, а также принесёт пользу open source сообществу. Ещё раз напомню, что мы принимаем заявки на включение дополнительных проектов в регулярную проверку – мы не обещаем, что добавим проект, но обязательно рассмотрим все ваши предложения.