Статический анализ кода — это важная составляющая всех современных проектов. Еще более значимым является его правильное применение. Мы решили организовать регулярную проверку некоторых открытых проектов, чтобы увидеть эффект от частого прогона анализатора. Мы используем анализатор PVS-Studio для проверки проектов, а просматривать результаты будем при помощи SonarQube. Так наши подписчики будут узнавать о новых интересных багах в только что написанном коде. Думаем, это будет забавно.
Почему же все-таки важна регулярная проверка проектов? Если запускать статический анализ редко, например, только перед релизом, то можно "утонуть" в большом количестве предупреждений и, просматривая их все, можно пропустить действительно важные срабатывания анализатора, указывающие на серьёзные ошибки. Если же запускать анализ регулярно, например, каждый день, то количество срабатываний будет не таким большим, и можно достаточно легко выявить действительно важные проблемы. Другая причина — это цена ошибки: чем раньше проблема будет обнаружена, тем дешевле ее устранить. Например, если запускать статический анализ только перед релизом, то к этому моменту большинство ошибок будет найдено отделом тестирования и исправлено, но такие исправления стоят дороже. То есть регулярный анализ – это единственно правильный способ использования статического анализа.
Как вы, наверное, знаете, наша команда часто публикует отчёты о проверке проектов с открытым исходным кодом. Такие статьи безусловно интересно читать, и они приносят определённую пользу и самим проверяемым проектам – мы всегда отправляем отчёт о найденных подозрительных местах разработчикам. Однако, такие единичные проверки проектов имеют те же недостатки, что и описанный выше сценарий с нерегулярной проверкой кода только перед релизом. Большой отчёт сложно воспринимать, а многие ошибки, которые можно было бы найти и исправить сразу же после их попадания в код уже оказываются исправлены на других уровнях контроля качества (например, с помощью тестов).
Поэтому мы решили попробовать новый формат работы с open source проектами – регулярная, каждодневная проверка кода одного (для начала) проекта. При этом эта проверка будет настроена так, что каждый день потребуется смотреть срабатывания анализатора только на изменившемся или вновь написанном коде — это и значительно быстрее, чем просмотр полного отчёта анализатора, и, главное – позволит очень быстро обнаружить потенциальную ошибку. Когда же мы будем встречать что-то действительно интересное, мы будем делать про это небольшие заметки или даже просто записи в Twitter.
Мы надеемся, что данный формат позволит нам как лучше популяризировать более правильную практику регулярного использования статического анализа, так и принесёт дополнительную пользу open source сообществу.
В качестве первого проекта для анализа мы решили выбрать проект Blender. Вы можете написать нам какие дополнительные проекты вы хотели бы, чтобы мы также регулярно анализировали и рассказывали про найденные в них ошибки.
Настройка регулярного анализа
Для нашей задачи самым оптимальным решением для регулярного анализа мы считаем cвязку инструментов PVS-Studio – SonarQube. Далее в статье мы расскажем про настройку выбранных инструментов: как запустить и настроить SonarQube, опишем как проанализировать проект и загрузить полученные результаты для отображения.
Почему мы выбрали SonarQube
PVS-Studio умеет многое: анализировать, рассылать уведомления о найденных предупреждениях, фильтровать их, но также еще умеет интегрироваться в разные системы для отображения предупреждений. Чтобы не только получать результаты проверки, но и дополнительно тестировать больше режимов работы PVS-Studio, мы решили попробовать настроить отображение результатов для нашей задачи в SonarQube.
Подробности о возможностях этого приложения можно прочитать тут. Мы же приступим к развертыванию. Все данные SonarQube хранит в базе данных. Можно использовать разные базы, но рекомендованной является PostgreSQL. Сначала настроим ее.
Настройка PostgreSQL
Скачаем последнюю версию здесь. Устанавливаем базу данных, создадим базу данных для использования SonarQube. Для этого сначала создадим пользователя с именем sonar – в командной строке psql выполним следующую команду:
CREATE USER sonar WITH PASSWORD '12345';
Для этой и других операций также можно использовать pgAdmin. Создадим базу с именем sonarqube при помощи команды CREATE DATABASE, в нашем случае так:
CREATE DATABASE sonarqube OWNER sonar;
База данных готова, приступим к настройке SonarQube.
Настройка 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/sonarqube
SonarQube увидит созданную нами базу и начнет с ней работать. Далее необходимо установить плагин для 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
Профиль качества (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.
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 сообществу. Ещё раз напомню, что мы принимаем заявки на включение дополнительных проектов в регулярную проверку – мы не обещаем, что добавим проект, но обязательно рассмотрим все ваши предложения.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Evgeniy Ovsyannikov. Just for Fun: PVS-Studio Team Came Up With Monitoring Quality of Some Open Source Projects.