Мы используем куки, чтобы пользоваться сайтом
было удобно.
Вебинар: Каждая идиома когда-то была проблемой - 11.09
У анализатора PVS-Studio уже десятки интеграций с различными инструментами и сервисами. В этой статье хотелось бы рассказать, зачем вообще мы это делаем.
Мы разрабатываем и продаём статический анализатор PVS-Studio. В самом продукте есть множество всякого интересного: утилиты командной строки, диагностические правила разных категорий, вспомогательные утилиты и тому подобное.
За не самым красивым оборотом "тому подобное" мы обычно скрываем наши многочисленные интеграции со сторонними продуктами (плагины, расширения, сценарии работы). Вы можете спросить: "А зачем скрывать?" Смотрите сами: первой нашей интеграцией был плагин для Visual Studio 2008, вышедший 18 лет назад. Сегодня же анализатор интегрируется с более чем тремя десятками других инструментов для разработки: плагины для IDE, игровые движки, платформы контроля качества кода, сборочные системы, платформы CI/CD и т. п.
Поддерживать всё это в актуальном и рабочем состоянии — большая работа, и сейчас расскажем, зачем мы вообще этим занимаемся.
Самое страшное, что видится при мысли о новом инструменте, — сложность процесса его внедрения. Причём такой страх возникает как у ответственных менеджеров, так и у рядовых инженеров (всегда помним про принцип "работает — не трогай").
Это вполне нормальная история, потому что в каждой компании или команде есть свои подходы и инструменты. И когда нужно внедрить что-то новое, это видится сложным. Да и вопрос не только в ощущениях — зачастую процесс внедрения действительно довольно сложный.
Собственно, это главная причина, по которой мы стараемся развивать интеграции для популярных инструментов. Если вы уже пользуетесь определённым набором IDE или конкретным веб-дашбордом для DevSecOps, зачем заставлять вас использовать придуманный нами велосипед? Вместо этого мы предлагаем дополнить привычный набор возможностью работы с нашим инструментом.
А ещё для разных людей в команде могут быть нужны разные инструменты. Например, разработчику важно, чтобы статический анализатор было удобно запускать во время разработки, а менеджеру — быстро посмотреть статистику по срабатываниям в веб-дашборде. Поэтому мы и создаём такое большое количество интеграций.
Да, статический анализатор обычно не кажется сложным в использовании инструментом, но вот его первоначальная настройка весьма разнится в зависимости от проекта и необходимых сценариев работы.
Предлагаю посмотреть сценарии использования на конкретных примерах.
В первую очередь, конечно, статический анализатор работает на машинах разработчиков, чтобы они могли проверять написанный код до его попадания в систему контроля версий.
И, казалось бы, достаточно понятного и удобного CLI. Мы же инженеры, в конце-то концов. Но на самом деле здесь работает старое доброе "на вкус и цвет все фломастеры разные". Кому-то нравится одна определённая IDE, а кто-то готов продать душу за Vim.
Со всем этим нужно уметь работать, а поэтому у PVS-Studio есть плагины для всех наиболее популярных IDE, используемых для разработки на поддерживаемых нашими анализаторами языках:
Может показаться, что оно того не стоит, но на самом деле плагины для IDE позволяют нам максимально сократить путь пользователя от идеи до результата: открыли проект, нажали одну кнопку и результаты анализа будут доступны уже через несколько секунд или минут.
В результате мы делаем за пользователя всю скучную, но нужную работу: спрашиваем у сборочной системы язык, тип и особенности проекта; получаем список файлов для анализа; применяем необходимые настройки; визуализируем прогресс и результат, а также позволяем удобно пользоваться вспомогательными инструментами.
Например, один из вариантов подавления ложных срабатываний — специальные комментарии в коде. Если вы работаете из терминала, то это превращается в целый процесс:
Не то чтобы это трудно. Просто в плагине для IDE всё это можно сделать парой кликов без необходимости читать документацию.
Если же вариант с IDE пользователю не подходит, то в дело идут интеграции со сборочными системами. Например, анализ проектов на Java можно настроить с помощью интеграций в Gradle и Maven, а для CMake и вовсе есть две интеграции: с помощью нашего CMake-модуля и с помощью внутренних механизмов самой утилиты. Официальную интеграцию Kitware добавили в версии 4.3.0.
Об официальной интеграции в CMake мы писали в отдельной статье. Прочитать её можно по ссылке.
Следующий большой этап при использовании статического анализа — его внедрение в CI для автоматического контроля входящих изменений. Этот этап подразумевает множество вариантов реализации, поэтому и список интеграций здесь весьма разнообразный.
Например, из on-premise решений есть интеграции с Jenkins и TeamCity, из облачных — GitHub Actions и GitLab CI/CD. Отечественные решения мы также не обходим стороной, поэтому PVS-Studio поддерживает интеграцию с GitFlic, GitVerse и SourceCraft.
Для автоматизации также может быть полезна возможность работы инструмента в средствах контейнеризации и виртуализации, например Docker и WSL.
Автоматический запуск статического анализа, кстати, важен не только для CI, но и для регулярного анализа.
Под регулярным анализом я имею в виду периодический запуск анализа всего проекта во время ночных сборок. Благодаря этому мы сможем понять, есть ли какие-то ошибки во всём проекте в целом, потому что при локальном анализе и в CI мы чаще всего проверяем только отдельные изменения.
Для этого этапа, помимо интеграций из прошлого пункта, нам также могут понадобиться веб-дашборды и системы контроля качества кода: анализ всего проекта происходит на сервере, и нам необходимо обеспечить возможность совместной работы всей команды над полученным отчётом.
Причём эта совместная работа включает в себя как просмотр отчёта, так и разметку предупреждений. Для менеджеров есть функционал для сбора различных метрик и распределения работы по обработке результатов между командой.
Платформа контроля качества кода выступает централизованным хранилищем информации о том, как изменялось качество кода в проекте с течением времени, поэтому для менеджера этот инструмент имеет практическую пользу.
Из веб-дашбордов PVS-Studio поддерживает интеграции в SonarQube, DefectDojo и CodeChecker.
Также поддерживается интеграция PVS-Studio в ряд российских решений:
Ну и уделим немного времени сферам разработки со своей спецификой. Здесь причины для поддержки интеграций те же, что описаны выше, отличаются только используемые инструменты.
Во-первых, это разработка игр. Для игровых проектов мы поддерживаем интеграции с движками Unreal Engine и Unity.
Во-вторых, это разработка встраиваемых систем. В силу специфики в embedded есть огромное количество различных компиляторов, которые сильно отличаются между собой. Поэтому мы стараемся поддерживать работу анализатора с теми компиляторами и SDK, которыми пользуются наши клиенты: IAR Embedded Workbench, QNX Momentics, Keil µVision, Texas Instruments Code Composer Studio, Нейтрино и прочие. Полный список всегда доступен на сайте.
Надеемся, у нас получилось объяснить, что интеграции для PVS-Studio — это не способ закрыть какой-то чек-лист. С их помощью мы стараемся сделать статический анализ удобной и незаметной частью рабочего процесса.
Начиная с первого плагина для Visual Studio 2008 и до сегодняшних дней мы работаем над тем, чтобы PVS-Studio приходил туда, где работает пользователь, а не наоборот.
Если вы ещё не пробовали проверить свой проект с помощью нашего анализатора, можно начать с этой страницы.
А если вы уже пользуетесь PVS-Studio и вам есть что об этом сказать, можете написать нам с помощью этой формы. Например, нам было бы интересно узнать, каких интеграций вам не хватает в продукте.
Чистого вам кода, друзья!
0
0
0
0