metrica
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо
to the top
close form

Заполните форму в два простых шага ниже:

Ваши контактные данные:

Шаг 1
Поздравляем! У вас есть промокод!

Тип желаемой лицензии:

Шаг 2
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности
close form
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Бесплатная лицензия PVS‑Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
check circle
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

Вебинар: Трудности при интеграции SAST, как с ними справляться - 04.04

>
>
>
Just for fun: команда PVS-Studio придум…

Just for fun: команда PVS-Studio придумала мониторить качество некоторых открытых проектов

11 Фев 2021

Статический анализ кода — это важная составляющая всех современных проектов. Еще более значимым является его правильное применение. Мы решили организовать регулярную проверку некоторых открытых проектов, чтобы увидеть эффект от частого прогона анализатора. Мы используем анализатор PVS-Studio для проверки проектов, а просматривать результаты будем при помощи SonarQube. Так наши подписчики будут узнавать о новых интересных багах в только что написанном коде. Думаем, это будет забавно.

0799_SonarRegularUse_ru/image1.png

Почему же все-таки важна регулярная проверка проектов? Если запускать статический анализ редко, например, только перед релизом, то можно "утонуть" в большом количестве предупреждений и, просматривая их все, можно пропустить действительно важные срабатывания анализатора, указывающие на серьёзные ошибки. Если же запускать анализ регулярно, например, каждый день, то количество срабатываний будет не таким большим, и можно достаточно легко выявить действительно важные проблемы. Другая причина — это цена ошибки: чем раньше проблема будет обнаружена, тем дешевле ее устранить. Например, если запускать статический анализ только перед релизом, то к этому моменту большинство ошибок будет найдено отделом тестирования и исправлено, но такие исправления стоят дороже. То есть регулярный анализ – это единственно правильный способ использования статического анализа.

Как вы, наверное, знаете, наша команда часто публикует отчёты о проверке проектов с открытым исходным кодом. Такие статьи безусловно интересно читать, и они приносят определённую пользу и самим проверяемым проектам – мы всегда отправляем отчёт о найденных подозрительных местах разработчикам. Однако, такие единичные проверки проектов имеют те же недостатки, что и описанный выше сценарий с нерегулярной проверкой кода только перед релизом. Большой отчёт сложно воспринимать, а многие ошибки, которые можно было бы найти и исправить сразу же после их попадания в код уже оказываются исправлены на других уровнях контроля качества (например, с помощью тестов).

Поэтому мы решили попробовать новый формат работы с 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, как показано на рисунке ниже.

0799_SonarRegularUse_ru/image2.png

В появившемся окне введем имя профиля (оно может быть произвольным), в нашем случае PVS-Studio Way, и выберем язык – для нас сейчас актуален C++. После этого нажмем кнопку Create.

0799_SonarRegularUse_ru/image3.png

Потом переходим на вкладку Rules, там выбираем категорию Repository и в ней выбираем пункт PVS-Studio C++. Далее нажимаем кнопку Bulk Change и Activate In, в появившемся окне выбираем наш созданный профиль, то есть PVS-Studio Way.

0799_SonarRegularUse_ru/image4.png

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 сообществу. Ещё раз напомню, что мы принимаем заявки на включение дополнительных проектов в регулярную проверку – мы не обещаем, что добавим проект, но обязательно рассмотрим все ваши предложения.

Популярные статьи по теме


Комментарии (0)

Следующие комментарии next comments
close comment form