# Зачем мы интегрируем свой анализатор в такое количество инструментов? У анализатора PVS\-Studio уже десятки интеграций с различными инструментами и сервисами\. В этой статье хотелось бы рассказать, зачем вообще мы это делаем\. ![1410_why_are_we_making_integrations_ru/image1.jpg](https://import.viva64.com/docx/blog/1410_why_are_we_making_integrations_ru/image1.jpg) Мы разрабатываем и продаём статический анализатор PVS\-Studio\. В самом продукте есть множество всякого интересного: утилиты командной строки, диагностические правила разных категорий, вспомогательные утилиты и тому подобное\. За не самым красивым оборотом "тому подобное" мы обычно скрываем наши многочисленные интеграции со сторонними продуктами \(плагины, расширения, сценарии работы\)\. Вы можете спросить: "А зачем скрывать?" Смотрите сами: первой нашей интеграцией был плагин для Visual Studio 2005, вышедший 18 лет назад\. Сегодня же анализатор интегрируется с более чем [тремя десятками других инструментов для разработки](https://pvs-studio.ru/ru/pvs-studio/#integration): плагины для IDE, игровые движки, платформы контроля качества кода, сборочные системы, платформы CI/CD и т\. п\. Поддерживать всё это в актуальном и рабочем состоянии — большая работа, и сейчас расскажем, зачем мы вообще этим занимаемся\. ## Удобство пользователя Самое страшное, что видится при мысли о новом инструменте, — сложность процесса его внедрения\. Причём такой страх возникает как у ответственных менеджеров, так и у рядовых инженеров \(всегда помним про принцип "работает — не трогай"\)\. Это вполне нормальная история, потому что в каждой компании или команде есть свои подходы и инструменты\. И когда нужно внедрить что\-то новое, это видится сложным\. Да и вопрос не только в ощущениях — зачастую процесс внедрения действительно довольно сложный\. Собственно, это главная причина, по которой мы стараемся развивать интеграции для популярных инструментов\. Если вы уже пользуетесь определённым набором IDE или конкретным веб\-дашбордом для DevSecOps, зачем заставлять вас использовать придуманный нами велосипед? Вместо этого мы предлагаем дополнить привычный набор возможностью работы с нашим инструментом\. А ещё для разных людей в команде могут быть нужны разные инструменты\. Например, разработчику важно, чтобы статический анализатор было удобно запускать во время разработки, а менеджеру — быстро посмотреть статистику по срабатываниям в веб\-дашборде\. Поэтому мы и создаём такое большое количество интеграций\. ## Сценарии использования Да, статический анализатор обычно не кажется сложным в использовании инструментом, но вот его первоначальная настройка весьма разнится в зависимости от проекта и необходимых сценариев работы\. Предлагаю посмотреть сценарии использования на конкретных примерах\. ### Локальный анализ В первую очередь, конечно, статический анализатор работает на машинах разработчиков, чтобы они могли проверять написанный код до его попадания в систему контроля версий\. И, казалось бы, достаточно понятного и удобного CLI\. Мы же инженеры, в конце\-то концов\. Но на самом деле здесь работает старое доброе "на вкус и цвет все фломастеры разные"\. Кому\-то нравится одна определённая IDE, а кто\-то готов продать душу за Vim\. Со всем этим нужно уметь работать, а поэтому у PVS\-Studio есть плагины для всех наиболее популярных IDE, используемых для разработки на поддерживаемых нашими анализаторами языках: * [Visual Studio](https://pvs-studio.ru/ru/docs/manual/6522/) * [Visual Studio Code](https://pvs-studio.ru/ru/docs/manual/6646/) * [WebStorm и PhpStorm](https://pvs-studio.ru/ru/docs/manual/7189/) * [GoLand](https://pvs-studio.ru/ru/docs/manual/7190/) * [IntelliJ IDEA и OpenIDE](https://pvs-studio.ru/ru/docs/manual/6704/) * [Rider](https://pvs-studio.ru/ru/docs/manual/0052/) * [CLion](https://pvs-studio.ru/ru/docs/manual/0052/) * [Qt Creator](https://pvs-studio.ru/ru/docs/manual/6648/) Может показаться, что оно того не стоит, но на самом деле плагины для IDE позволяют нам максимально сократить путь пользователя от идеи до результата: открыли проект, нажали одну кнопку и результаты анализа будут доступны уже через несколько секунд или минут\. В результате мы делаем за пользователя всю скучную, но нужную работу: спрашиваем у сборочной системы язык, тип и особенности проекта; получаем список файлов для анализа; применяем необходимые настройки; визуализируем прогресс и результат, а также позволяем удобно пользоваться вспомогательными инструментами\. Например, один из вариантов подавления ложных срабатываний — [специальные комментарии в коде](https://pvs-studio.ru/ru/docs/manual/0017/)\. Если вы работаете из терминала, то это превращается в целый процесс: 1. Находим в файле отчёта позицию срабатывания; 1. Переходим на эту позицию в файле; 1. Ставим комментарий с номером диагностического правила; 1. ~~Вспоминаем, как выйти из Vim~~\. Не то чтобы это трудно\. Просто в плагине для IDE всё это можно сделать парой кликов без необходимости читать документацию\. Если же вариант с IDE пользователю не подходит, то в дело идут интеграции со сборочными системами\. Например, анализ проектов на Java можно настроить с помощью интеграций в [Gradle](https://pvs-studio.ru/ru/docs/manual/6706/) и [Maven](https://pvs-studio.ru/ru/docs/manual/6705/), а для CMake и вовсе [есть две интеграции](https://pvs-studio.ru/ru/docs/manual/6591/): с помощью нашего CMake\-модуля и с помощью внутренних механизмов самой утилиты\. Официальную интеграцию Kitware добавили в версии 4\.3\.0\. > Об официальной интеграции в CMake мы писали в отдельной статье\\\. Прочитать её можно по \[ссылке\]\(https://pvs\-studio\.ru/ru/blog/posts/cpp/1374/\)\\\. ### Непрерывный анализ Следующий большой этап при использовании статического анализа — его внедрение в CI для автоматического контроля входящих изменений\. Этот этап подразумевает множество вариантов реализации, поэтому и список интеграций здесь весьма разнообразный\. Например, из on\-premise решений есть интеграции с [Jenkins](https://pvs-studio.ru/ru/docs/manual/0048/) и [TeamCity](https://pvs-studio.ru/ru/docs/manual/0049/), из облачных — [GitHub Actions](https://pvs-studio.ru/ru/docs/manual/6579/) и [GitLab CI/CD](https://pvs-studio.ru/ru/docs/manual/0056/)\. Отечественные решения мы также не обходим стороной, поэтому PVS\-Studio поддерживает интеграцию с [GitFlic](https://pvs-studio.ru/ru/docs/manual/7176/), [GitVerse](https://habr.com/ru/companies/pvs-studio/news/1059090/) и [SourceCraft](https://pvs-studio.ru/ru/docs/manual/7186/)\. Для автоматизации также может быть полезна возможность работы инструмента в средствах контейнеризации и виртуализации, например [Docker](https://pvs-studio.ru/ru/docs/manual/0047/) и [WSL](https://pvs-studio.ru/ru/docs/manual/0036/)\. Автоматический запуск статического анализа, кстати, важен не только для CI, но и для регулярного анализа\. ### Регулярный анализ Под регулярным анализом я имею в виду периодический запуск анализа всего проекта во время ночных сборок\. Благодаря этому мы сможем понять, есть ли какие\-то ошибки во всём проекте в целом, потому что при локальном анализе и в CI мы чаще всего проверяем только отдельные изменения\. Для этого этапа, помимо интеграций из прошлого пункта, нам также могут понадобиться веб\-дашборды и системы контроля качества кода: анализ всего проекта происходит на сервере, и нам необходимо обеспечить возможность совместной работы всей команды над полученным отчётом\. Причём эта совместная работа включает в себя как просмотр отчёта, так и разметку предупреждений\. Для менеджеров есть функционал для сбора различных метрик и распределения работы по обработке результатов между командой\. Платформа контроля качества кода выступает централизованным хранилищем информации о том, как изменялось качество кода в проекте с течением времени, поэтому для менеджера этот инструмент имеет практическую пользу\. Из веб\-дашбордов PVS\-Studio поддерживает интеграции в [SonarQube](https://pvs-studio.ru/ru/docs/manual/0037/), [DefectDojo](https://pvs-studio.ru/ru/docs/manual/6686/) и [CodeChecker](https://pvs-studio.ru/ru/docs/manual/6819/)\. Также поддерживается интеграция PVS\-Studio в ряд российских решений: * [AppSec\.Hub](https://pvs-studio.ru/ru/docs/manual/7177/) * [Hexway](https://pvs-studio.ru/ru/docs/manual/7178/) * [Securitm](https://pvs-studio.ru/ru/docs/manual/7179/) * [TRON\.ASOC](https://pvs-studio.ru/ru/docs/manual/7182/) * [CyberCodeReview](https://pvs-studio.ru/ru/docs/manual/7181/) ## Специфичные сценарии Ну и уделим немного времени сферам разработки со своей спецификой\. Здесь причины для поддержки интеграций те же, что описаны выше, отличаются только используемые инструменты\. Во\-первых, это разработка игр\. Для игровых проектов мы поддерживаем интеграции с движками [Unreal Engine](https://pvs-studio.ru/ru/docs/manual/0043/) и [Unity](https://pvs-studio.ru/ru/docs/manual/6607/)\. Во\-вторых, это разработка встраиваемых систем\. В силу специфики в embedded есть огромное количество различных компиляторов, которые сильно отличаются между собой\. Поэтому мы стараемся поддерживать работу анализатора с теми компиляторами и SDK, которыми пользуются наши клиенты: IAR Embedded Workbench, QNX Momentics, Keil µVision, Texas Instruments Code Composer Studio, Нейтрино и прочие\. Полный список всегда доступен [на сайте](https://pvs-studio.ru/ru/pvs-studio/#languages_and_compilers)\. ## Заключение Надеемся, у нас получилось объяснить, что интеграции для PVS\-Studio — это не способ закрыть какой\-то чек\-лист\. С их помощью мы стараемся сделать статический анализ удобной и незаметной частью рабочего процесса\. Начиная с первого плагина для Visual Studio 2005 и до сегодняшних дней мы работаем над тем, чтобы PVS\-Studio приходил туда, где работает пользователь, а не наоборот\. Если вы ещё не пробовали проверить свой проект с помощью нашего анализатора, можно [начать с этой страницы](https://pvs-studio.ru/ru/pvs-studio/try-free/)\. А если вы уже пользуетесь PVS\-Studio и вам есть что об этом сказать, можете [написать нам с помощью этой формы](https://pvs-studio.ru/ru/about-feedback/)\. Например, нам было бы интересно узнать, каких интеграций вам не хватает в продукте\. Чистого вам кода, друзья\!