Использование PVS-Studio вместе с системами continuous integration

21.05.2013

Аннотация

В статье показаны приемы организации работы анализатора кода PVS-Studio вместе с системами непрерывной интеграции (continuous integration). Приведены примеры настройки запуска PVS-Studio.

Введение

Непрерывная интеграция (continuous integration, CI) — это практика разработки программного обеспечения, предполагающая частую сборку и последующее тестирование текущей версии продукта. Системы непрерывной интеграции, как правило, взаимодействуют напрямую с системами контроля версий и позволяют значительно повысить надёжность интеграционного процесса и снизить его трудоёмкость за счёт полной автоматизации всех этапов сборки и тестирования.

Для использования в системах непрерывной интеграции PVS-Studio предусматривает возможность "тихого запуска" анализа тестируемого проекта из командной строки. Подобная интеграция PVS-Studio в процесс регулярных сборок позволит эффективно использовать результаты анализа при групповой работе над проектом.

Использование функции "Mark As False Alarm" в процессе автоматизации тестирования

При запуске анализа из командной строки PVS-Studio каждый раз будет осуществлять проверку всего кода тестируемого проекта. Такой подход к проверке обусловлен тем, что изменения в одном заголовочном h-файле часто могут затрагивать более чем один cpp файл, и поэтому проверки только модифицированных или новых файлов, а не всего решения, недостаточно.

Но стоит помнить, что методика статического анализа предполагает генерацию анализатором большого числа т.н. "ложных срабатываний" и для подавления этого "шума" очень важно при регулярной проверке кода с помощью PVS-Studio пользоваться функцией "Mark as False Alarm". Работу с анализатором PVS-Studio можно разделить на 2 этапа: внедрение и постоянное использование. На этапе внедрения анализатора в систему непрерывной интеграции программист должен просмотреть все полученные сообщения об ошибках и либо исправить соответствующий им код, либо разметить его как ложные срабатывания. После этого на этапе тестирования анализатор будет генерировать сообщения только для добавленного в проект нового кода.

Интеграция PVS-Studio с системами непрерывной сборки (continuous integration)

В связи с тем, что PVS-Studio включает плагины-расширения для сред разработки Microsoft Visual Studio/Embarcadero RAD Studio, возможна интеграция анализатора в любую систему CI, способную запускать сборки для данных IDE из командной строки с передачей аргументов. При этом от CI системы не требуется прямая поддержка сборок в них, достаточно лишь иметь возможность передавать команды интерпретатору командной строки ОС и обрабатывать стандартный поток вывода stdout.

Как вызывать анализатор для проверки из командной строки, подробно показано в отдельной статье.

Открытие лог-файла результата в IDE (двойным щелчком мыши напрямую из файлового менеджера или через меню PVS-Studio/Load Analysys Report) позволяет осуществлять навигацию по фрагментам кода проанализированного проекта, содержащим ошибки. Поскольку сам XML лог-файл не удобен для чтения, анализатор генерирует в том же каталоге текстовый файл, содержащий простой список ошибок (не помеченных как False Alarm), обнаруженных PVS-Studio. Такой файл наглядно демонстрирует результаты анализа, и поэтому его удобно присоединять к общим отчётам CI системы о сборке, которые могут, к примеру, рассылаться по электронной почте всем заинтересованным разработчикам.

В случае, когда проверка всех файлов проектов не является целесообразной, PVS-Studio может осуществить проверку только файлов, модифицированных в течение заданного интервала времени. Данный временной интервал может быть задан на странице SpecificAnalyzerSettings настроек анализатора. Альтернативно, файлы для проверки также могут быть указаны явно с использованием пакетного режима работы.

Пакетный режим работы при запуске анализатора из командной строки

При запуске анализа из командной строки PVS-Studio по умолчанию проверяет все файлы, включённые в указанные проекты. Однако при наличии необходимости проверить только определённый набор файлов может быть использован пакетный режим работы, в котором анализу подвергнуться только те файлы, пути к которым прописаны явно. Об этом режиме запуска (с параметром filelist-file) также говорится в отдельной статье.

Пример интеграции PVS-Studio плагина для Visual Studio с системой CruiseControl .NET

Интеграция анализатора PVS-Studio в систему CruiseControl.NET может быть осуществлена путём добавления в необходимый сборочный проект (build project) задачи (сборочного шага) типа Executable, в которой будет вызван интерпретатор командной строки Windows cmd.exe. Ниже приведён фрагмент конфигурационного файла сервера CruiseControl.NET, в котором описана подобная сборочная задача.

<exec>
 <description>PVS-Studio check solution example</description>
 <executable>&CMD_PATH;</executable>
 <baseDirectory>&DEVENV_PATH;<baseDirectory>
 <buildArgs>
  <item>
  /c devenv.exe "C:\sample\VSSol.sln" /command
 "PVSStudio.CheckSolution Win32|Release|C:\sample\ result-log.plog" 
  </item>
 </buildArgs>
 </exec>

Результаты анализа, содержащиеся в файле result-log.plog.only_new_messages.txt, могут быть опубликованы любыми задачами публикации (publisher tasks), например копированием файла в общий сборочный каталог или рассылкой сборочного лога сервера по электронной почте. Для включения результатов анализа в общий лог можно воспользоваться сборочной задачей Executable:

<exec>
 <description>PVS-Studio load error log</description>
 <executable>&CMD_PATH;</executable>
 <baseDirectory>&PROJECT_ROOT;</baseDirectory>
 <buildArgs>
  <item>
  /c type result-log.plog.only_new_messages.txt
  </item>
 </buildArgs>
 <buildTimeoutSeconds>0</buildTimeoutSeconds>
</exec>

Интеграция с системой Hudson

Для интеграции анализатора PVS-Studio с системой Hudson необходимо в требуемый проект (Job) добавить шаг сборки "Выполнить команду Windows". Пример такой команды:

devenv.exe "C:\sample\VSSol.sln" /command "PVSStudio.CheckSolution
Win32|Release|C:\sample\ result-log.plog" 

Полученный в результате анализа текстовый файл result-log.plog.only_new_messages.txt, содержащий полный список не размеченных как ложные срабатывания ошибок, можно присоединить к общему логу сборки проекта, дополнительно добавив команду

type result-log.plog.only_new_messages.txt

В дальнейшем полученный лог может быть опубликован с использованием любых встроенных в систему Hudson механизмов. Например, для публикации результатов сборки по электронной почте можно воспользоваться расширением ext-email, добавив в тело письма лексему (token) $BUILD_LOG:

${BUILD_LOG, maxLines=5000}

Интеграция с Microsoft Team Foundation Server 2005/2008/2010

Использование анализатора PVS-Studio совместно со сборочным сервером Team Foundation осложнено наличием тесной интеграции проектов Visual Studio с системой контроля версий от Microsoft, и поэтому требует дополнительных шагов по сравнению с системами непрерывной интеграции других компаний в случае, если в качестве системы контроля версий также используется Microsoft Team Foundation. Заметим, что сборочный сервер TFS использует утилиту MSBuild для сборок и не требует для своей работы среды Visual Studio. В связи с тем, что PVS-Studio является надстройкой – расширением для Visual Studio, обязательным требованием является наличие доступа сборочного сервера TFS к среде Visual Studio (в частности к devenv.exe) с установленным анализатором PVS-Studio.

Типичная сборка в TFS с использованием анализатора PVS-Studio будет включать следующий минимальный набор обязательных этапов:

  • Сервер загружает из системы контроля версий исходные тексты нужных проектов в заданную локальную директорию.
  • Исходные тексты программ проверяются анализатором PVS-Studio (для этого необходимо вызвать devenv.exe с командой /command PVSStudio.Checksolution), результаты анализа сохраняются в указанную локальную директорию.
  • Сервер производит сборку проектов с помощью MSBuild.
  • Результаты проверки и сборки публикуются в указанной для данной сборки директории.

Team Foundation 2010 Build Server

Для интеграции проверки анализатором PVS-Studio (шаг 2) в сборочный процесс сервера Team Foundation 2010 нужно добавить сборочное действие (Build Activity) типа InvokeProcess в сценарий сборки определения сборки (Build Definition), описанный в xaml файле (пункт меню Edit Build Defenition на нужном определении сборки, вкладка Process, поле Build Process Template), которому в качестве атрибута Filename необходимо передать путь до PVS-Studio.exe и в качестве атрибута Arguments строку:

--sln-file VSSol.sln --plog-file result-log.plog --vcinstalldir "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC" --platform "Win32" --configuration "Release"

Team Foundation 2005/2008 Build Server

Для интеграции проверки анализатором PVS-Studio (шаг 2) в сборочный процесс сервера Team Foundation 2005/2008 нужно для интересующего определения сборки (Build Definition) модифицировать соответствующий ему проект MSBuild (файл с расширением proj), добавив в него сборочную задачу типа Exec. (задача Exec должны быть наследником одного из узлов типа Target, объединяющего сборочные задачи MSBuild) В качестве атрибута command следует указать строку такого вида:

PVS-Studio.exe --sln-file VSSol.sln --plog-file result-log.plog --vcinstalldir "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC" --platform "Win32" --configuration "Release"

Запуск сборок Team Foundation System в интерактивном режиме рабочего стола

Сборочный сервер Team Foundation System по умолчанию запускает сборки, используя локальную системную учётную запись (NT AUTHORITY\SYSTEM) или учётную запись локальной службы (Local Service), в неинтерактивном режиме, т.е. работает в виде Windows – сервиса, не имея возможности взаимодействовать с рабочим столом пользователя. Для корректной работы среды Visual Studio рекомендуется использовать интерактивный режим сборок. Для запуска интерактивной сборки необходимо запустить сборочный сервис Team Foundation Build из-под учётной записи пользователя, имеющей доступ к рабочему столу (например, ваша текущая учётная запись). В системе Team Foundation 2008 этот сервис должен быть запущен вручную (C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\ TFSBuildService.exe). В системе Team Foundation 2010 параметры запуска сервиса можно изменить в утилите конфигураторе сервера.

При первом запуске devenv.exe из-под локальной системной учётной записи (NT AUTHORITY\SYSTEM) в неинтерактивном режиме, Visual Studio выдаёт диалоговое окно, позволяющее выбрать один из шаблонов настроек среды. Это диалоговое окно также блокирует работу анализатора PVS-Studio, поэтому его требуется один раз закрыть вручную, что невозможно сделать для приложения, запущенного в неинтерактивном режиме. Однако, начиная с Windows Vista, приложениям, запущенным из-под локальной системной учётной записи не разрешено запускаться в интерактивном режиме. Для того чтобы запустить devenv.exe от имени локальной системной учётной записи в интерактивном режиме можно воспользоваться программой PsExec из набора утилит PSTools. psexec.exe –i –s %devenvPath%.

Проверка проектов Visual Studio, использующих Team Foundation Server source control

Если в качестве системы контроля версий также используется Microsoft Team Foundation (TFS версий 2008/2010), подобный режим запуска делает невозможным открытие и последующий анализ solution файлов среды Visual Studio, содержащих метаинформацию системы контроля версий TFS, т.к. выдаваемые средой диалоговые окна блокируют работу расширения PVS-Studio. PVS-Studio не поддерживает проверку с запуском из командной строки проектов, содержащих метаинформацию системы контроля версий TFS 2008/2010.

Для запуска проверки проектов Visual C++ анализатором PVS-Studio из сборочного сервера Team Foundation System, использующего систему контроля версий Team System, необходимо перед началом проверки очистить sln и проектные (vcxproj) файлы от метаинформации системы контроля версий TFS. Это можно сделать, не прерывая сборочного процесса и в автоматическом режиме, с помощью консольной утилиты TFSRipper. Для этого необходимо добавить её вызов до и после вызова devenv.exe, также используя сборочное действие InvokeProcess. При этом первый раз ей нужно передать аргумент вида: %LocalSourcePath% - путь до выкачанных сборочным сервером исходных текстов программ, которые будут проверяться анализатором, а второй раз аргумент вида: %LocalSourcePath% \restore. Утилита обработает все sln и vcxproj файлы, удалив из них метаинформацию системы контроля версий и предварительно создав копии данных файлов (с расширением pvsbak), а после повторного её вызова с аргументом /restore восстановит эти файлы из созданных ранее копий.