какие метрики не входят в рекомендованный профиль качества quality gate
Quality Gates: как мы встраиваем автоматические проверки кода в свои процессы
Quality Gates – это автоматические проверки качества, которые устанавливают пороговые значения для продвижения продукта по конвейеру разработки. Рассказываем, как работает эта технология, и поделимся дорожной картой, которую мы составили, чтобы внедрить Quality Gates во всех наших командах.
Принцип Quality Gates – буквально «ворота качества» – помогает решать проблемы в коде на ранних этапах, до того, как он обрастёт зависимостями. Если в коде есть дублирование, обнаруживаются проблемы с переменными или не хватает тестов, он не «проходит в ворота» и возвращается автору. В результате код становится чище и понятнее, баги оказывается проще исправлять, да и появляются они реже.
Три причины внедрить Quality Gates
Компания выравнивает качество своих продуктов. У всех команд появляются единые требования к качеству кода, общее видение стилей программирования, безопасности продукта, качества продукта в целом. Более того компания может централизовано обновлять требования для всех проектов сразу.
Разработчики избавляются ещё от одной части ручной работы.
Команда получает автоматический отчет со значениями ключевых метрик и объяснением, почему тот или иной код или алгоритм считается плохим.
Пошаговый план внедрения
Начинать эксперименты с Quality Gates стоит со статического анализа кода. Этот метод помогает командам избавиться от общих ошибок, вычистить код от шероховатостей и некоторых пробелов безопасности. Подчеркнём слово «некоторых» – чтобы в продукте не было уязвимостей, требуются специальные проверки.
Мы выбрали для статического анализа SonarQube, популярное open source решение, которое поддерживает пару десятков языков программирования. Важный для нас момент – есть интеграция с нашим инструментом контроля версий – TFS, так что мы можем делать готовые пайплайны с уже включёнными проверками кода.
Полезные выводы по результатам пилота
Уже после тестовых прогонов на нескольких десятках проектов мы смогли оценить эффективность и ограничения инструмента.
«С высоты птичьего полёта» отчетливо увидели, как у разных команд формируется собственный стиль – разработчики бессознательно формируют общий подход к написанию кода, в итоге внутри каждой команды появляются одни и те же недочёты. С Quality Gates такую ситуацию можно исправить у всех разом.
Первые результаты с сотнями ошибок на большой проект логко могут деморализовать. Важно понимать, что обращать внимание нужно не на общее количество проблем, а на их разнообразие. Чем меньше типов ошибок, тем быстрее можно всё исправить.
Для iOS-продуктов нужны дополнительные средства – базовая версия SonarQube не поддерживает Swift и Objective-С. В платной правил проверки для iOS в SonarCube в разы меньше, чем для Java/C#, к тому же нет одновременной проверки Swift и ObjC, а у нас большинство продуктов содержат код на обоих языках.
Для полноценной защиты продукта обязательно нужны дополнительные средства. Мы сопоставили список уязвимостей, которые нашёл SonarQube на одном из приложений, с результатами полноценного аудита безопасности. Совпадение обнаружилось только в одном случае – SonarQube не хватает динамических проверок, да и стандартный список правил нужно расширять.
Заключение
Статический анализ – это отличная стартовая точка для внедрения Quality Gates. Он даёт быстрый эффект, помогает определиться, куда двигаться дальше.
Общие требования к качеству позволяют в любом проекте запускать проверки на основе этих правил, централизовано обновлять их для всех сразу. Результатом проверок будет отчет со значениями ключевых метрик и объяснением, почему тот или иной код или алгоритм считается плохим – улучшая эти значения, команда будет повышать качество продукта и развивать свои навыки.
Quality Gates
Overview
In order to answer this question, you define a set of Boolean conditions based on measure thresholds against which projects are measured. For example:
No new blocker issues
Code coverage on new code greater than 80%
Ideally, all projects will be verified against the same quality gate, but that’s not always practical. For instance, you may find that:
Technological implementation differs from one application to another (you might not require the same code coverage on new code for Web or Java applications).
You want to ensure stronger requirements on some of your applications (internal frameworks for example).
Which is why you can define as many quality gates as you wish. Quality Gates are defined and managed in the Quality Gates page found in the top menu.
Use the Best Quality Gate Configuration
The quality gate «SonarQube way» is provided by SonarSource and activated by default. It represents our view of the best way to implement the Fixing the Water Leak concept. At each SonarQube release, we adjust this default quality gate according to SonarQube’s capabilities.
With SonarQube 6.2 comes three new metrics allowing you to enforce a given Rating of Reliability, Security and Maintainability, not just overall but also on new code. These new metrics are now recommended and come as part of the default quality gate. We strongly advise you to adjust your own quality gates to use them to make feedback more clear to your developers looking at their quality gate on their project page.
Don’t forget also that quality gate conditions must use differential values. There is no point for example to check an absolute value such as : Number of Lines of Code is greater than 1000.
Recommended Quality Gate
Quality Gate Status
The current status is displayed prominently at the top of the Project Page :
Getting Notified When a Quality Gate Fails
Thanks to the notification mechanism, users can be notified when a quality gate fails. To do so, subscribe to the New quality gate status notification either for all projects or a set of projects you’re interested in.
Security
Quality Gates can be accessed by any user (even anonymous users). All users can view every aspect of a quality gate.
To make changes (create, edit or delete) users must be granted the Administer Quality Profiles and Gates permission.
A project administrator can choose which quality gates his/her project is associated with. See Project Settings for more.
Defining Quality Gates
To manage quality gates, go to Quality Gates (top menu bar).
Each Quality Gate condition is a combination of :
period: Value (to date) or Leak (differential value over the Leak period)
Отображение разработчикам статуса контроля качества исходного кода в SonarQube
SonarQube — это открытая платформа для обеспечения непрерывного контроля качества исходного кода, поддерживающая большое количество языков программирования и позволяющая получать отчеты по таким метрикам, как дублирование кода, соответствие стандартам кодирования, покрытие тестами, сложность кода, потенциальные ошибки и т.д. SonarQube удобно визуализирует результаты анализа и позволяет отслеживать динамику развития проекта во времени.
Задача: Показывать разработчикам статус контроля качества исходного кода в SonarQube.
Есть два способа решения:
Установка SonarQube
Для установки sonarqube из rpm пакетов воспользуемся репозиторием https://harbottle.gitlab.io/harbottle-main.
Установим пакет с репозиторием для CentOS 7.
Устанавливаем сам sonarqube.
При установке установятся большинство плагинов, но нужно доустановить findbugs и pmd
Запускаем сервис и добавляем в автозагрузку
Если долго загружается, то добавьте в конец опций sonar.web.javaOpts генератор случайных чисел /dev/./urandom
Запуск скрипта проверки статуса контроля качества исходного кода в SonarQube.
К сожалению, плагин sonar-break-maven-plugin давно не обновлялся. Поэтому напишем свой скрипт.
Отображение на главной странице проекта статус контроля качества исходного кода
Устанавливаем плагин для SonarQube
Заходим в SonarQube по адресу http://172.26.9.115:9000/
Создаем обычного пользователя, например «badges».
Заходим под этим пользователем в SonarQube.
Заходим в «My account», создаем новый токер, например с названием «read_all_repository» и нажимаем «Genereate».
Видим что появился токен. Он появлется только 1 раз.
Заходим под администратором.
Копируем этот токен в поле «Activity badge token» и нажимаем кнопку save.
У пользователя badges необходимо установить галку «Browse».
Импортируем этот проект.
В SonarQube проект будет выглядеть так:
Добавляем bages в README.md и они будут выглядeть так:
Код отображения badges выглядит так:
Разбор строки отображения badges:
Где взять/проверить Project Key и id-проекта.
Project Key находится справа внизу. В URL находится id-проекта.
Опции для получение метрик можно посмотреть тут.
Все pull request на улучшение, исправления ошибок присылайте в этот репозиторий.
Контролируем качество кода с помощью платформы SonarQube
В этой статье мы рассмотрим основные возможности SonarQube — платформы для непрерывного анализа и измерения качества кода, а также обсудим достоинства методики оценки качества кода на основе метрик SonarQube.
Введение
Наша компания занимается разработкой статического анализатора кода PVS-Studio. Мы убеждены, что выбор подходящей методологии разработки и следование ей, применение доказавших свою эффективность методик и инструментов существенно повышает вероятность того, что код будет написан правильно, и конечный продукт будет соответствовать требуемым стандартам качества. Одной из таких методологий является использование статического анализа исходного кода. Статический анализ, применяемый вместе с другими метриками кода, позволяет оценить текущее состояние кодовой базы, динамику этого состояния, возможные риски при реализации проекта.
Для начала расскажу вкратце о представлении результатов анализа PVS-Studio. Результаты работы нашего статического анализатора PVS-Studio сохраняются в формате xml. Список сообщений об обнаруженных ошибках можно открыть прямо в окне Microsoft Visual Studio или в отдельной утилите Standalone, и работать с этими ошибками, используя возможности навигации по коду, сортировки, фильтрации, подавления ложных срабатываний и т.д.
Список найденных ошибок в формате xml можно преобразовать в один из форматов, удобных для чтения, например, html. Такие отчеты с результатами анализа можно рассылать всем заинтересованным участникам проекта по почте. Другой способ оповещения участников проекта — рассылка списков ошибок тем разработчикам, которые их допустили. Для этого пользователи могут использовать специальные утилиты, поставляемые в дистрибутиве PVS-Studio.
Говоря о возможностях PVS-Studio, следует упомянуть о функциональности для массового подавления диагностических сообщений. Если статический анализ был внедрен на поздних этапах жизненного цикла приложения, когда объем кодовой базы достиг большого размера, инспекция кода может привести к обнаружению большого количества ошибок. Возможно, в данный момент времени у команды отсутствуют ресурсы, необходимые для исправления всех ошибок. В этом случае разработчики могут скрыть все сообщения, выданные на текущей ревизии кода, и сконцентрироваться на ошибках, найденных во вновь написанном или модифицированном коде.
Динамику количества ошибок, найденных PVS-Studio, можно получить, используя функциональность Analysis Statistics плагина PVS-Studio для Microsoft Visual Studio или утилиты Standalone:
Перечисленные способы представления результатов работы нашего статического анализатора, однако, существуют сами по себе и не связаны с другими метриками кода, такими как количество строк кода, цикломатическая сложность, количество ошибок на 1000 строк кода, уровень покрытия кода модульными тестами, дублирование и так далее. Отчет о найденных ошибках после очередного анализа и количество этих ошибок не дает ответов на вопросы: много у нас ошибок или мало? Как динамика количества ошибок связана с ростом кодовой базы? Улучшается или ухудшается качество кода? И, наверное, самый главный вопрос менеджеров: когда все будет работать (сколько времени потребуется, чтобы устранить ошибки)? Эти вопросы заставили нас задуматься о том, как придать отчетам PVS-Studio большую ценность и информативность.
Почему же полезно собирать и контролировать метрики кода? Невозможно улучшить то, что вы не измеряете. Предположим, какая-то команда не собирает метрики кода. С развитием проекта кодовая база может становиться все хуже и хуже, и долгое время никто этого даже не заметит, пока в какой-то момент объем технического долга не достигнет такого размера, что поддержка и добавление новой функциональности будет стоить дороже и дороже. Если бы команда постоянно отслеживала метрики кода, она бы видела динамику состояния своего проекта и, по достижению определенных пороговых значений, начала бы бить тревогу.
Далее, допустим, команда осознала проблему и убедила своего менеджера в том, что необходимо потратить ресурсы на улучшение качества кода. Менеджер, в свою очередь, задаст команде несколько простых вопросов: сколько времени понадобится на это команде? Какие части проекта необходимо улучшить? Сколько багов вы собираетесь исправить? По каким критериям вы оцените, что качество кода достигло требуемого уровня, и можно снова вернуться к разработке новой функциональности? Использование метрик позволит ответить на все эти вопросы. Если перед началом работ по улучшению качества кода команда зафиксирует текущее состояние кода по каждому компоненту продукта и определит пороговые значения для каждой метрики, достижение которых позволит с определенной степенью уверенности заявить, что код продукта стал качественным, можно спрогнозировать дату окончания работ и остановиться тогда, когда определенные пороговые значения будут достигнуты. Так, например, команда сможет показать менеджеру, что после окончания работ по повышению качества кода уровень покрытия модульными тестами достиг 90%, следование стандартам кодирования, принятым в компании, достигло 95%, а дублирование кода сократилось до 5%, и т.д.
Почему SonarQube?
SonarQube — это платформа с открытым исходным кодом, предназначенная для непрерывного анализа и измерения качества кода. SonarQube предоставляет следующие возможности:
Мы тщательно изучили возможности платформы SonarQube и решили, что эти возможности могут быть интересны нашим клиентам. Поэтому мы приняли решение о разработке плагина для импорта результатов анализа PVS-Studio.
Приблизительно в это же время один из наших клиентов выразил заинтересованность во внедрении централизованного хранилища различных метрик кода. Клиент разрабатывает очень крупный (более 10 миллионов строк кода) и долгосрочный (более 15 лет активной разработки) проект. Естественно, в таком проекте очень много унаследованного кода и связанных с ним скелетов в шкафу, и в этом случае, на мой взгляд, совершенно необходимо разработать и внедрить набор метрик, позволяющих оценить состояние кода проекта и динамику изменений этого состояния во времени. Естественно, наш клиент давно принял решение о сборе и анализе метрик, и внедрил различные утилиты для мониторинга показателей качества кода, таких как: покрытие кода модульными тестами, результаты прогона тестов, дублирование блоков кода, следование принятым стандартам кодирования, плотность комментариев в коде и т.д. Параллельно со сбором этих метрик ежедневно выполнялся статический анализ кода. Использование большого количества утилит приводило к усложнению конфигурации сервера непрерывной интеграции, написанию дополнительных скриптов для преобразования результатов работы каждой утилиты в удобный для представления вид и объединения всех показателей в единый отчет. Такой подход требовал значительных ресурсов на создание и поддержку этой системы отчетности.
Исходя из потребностей клиента и нашего исследования возможностей платформы SonarQube, мы предложили внедрить эту платформу. Что и было сделано. В рамках задачи по внедрению был реализован плагин для SonarQube, позволяющий импортировать в SonarQube результаты анализа PVS-Studio. Процесс развертывания SonarQube и его интеграции с имеющимся окружением (сборочная система, сервер непрерывной интеграции, система контроля версий) не вызвал затруднений благодаря логичным механизмам настройки и большого количества подробной документации. Были настроены виджеты, позволяющие оценивать как состояние портфолио проектов клиента в целом, так и состояние каждого проекта в отдельности, настроены Quality Profiles и Quality Gates (об этих механизмах SonarQube я расскажу ниже) согласно потребоностям клиента, автоматическое назначение задач на исполнителей, рассылка уведомлений всем заинтересованным лицам.
В результате внедрения SonarQube клиент получил централизованную систему хранения и отображения метрик кода, позволяющую оценивать и прогнозировать риски проекта. Переход от отдельных инструментов к централизованной системе контроля качества кода не только упрощает развертывание и поддержку этой системы, но и позволяет совершить качественный скачок в сфере управления проектами, предоставляя всем заинтересованным участникам средства для мониторинга состояния проекта и принятия взвешенных решений. После тестовой эксплуатации клиент принял решение о включении SonarQube в действующий набор инструментов ALM (Application Lifecycle Management).
Следует отметить, что SonarQube, благодаря своим широким возможностями интеграции с другими инструментами, легко может стать неотъемлемой частью вашего фреймворка ALM. С помощью плагинов в SonarQube можно добавить поддержку Git, SVN, Mercurial, Team Foundation Version Control, ClearCase, настроить авторизацию через LDAP, GitHub, Bitbucket, Azure Active Directory, импортировать результаты работы сторонних анализаторов. Плагины SonarLint для IntelliJ IDEA, Eclipse и Visual Studio позволяют анализировать код в режиме реального времени в вашей любимой IDE, используя правила, определенные в профиле SonarQube. Также доступна интеграция с Team Foundation Server и Visual Studio Team Services. Вы можете запустить анализ кода и импорт данных в SonarQube прямо из сборочного процесса в этих системах, или, например, управлять состоянием сборок в Team Foundation Server и Visual Studio Team Services с помощью Quality Gates (индикаторов качества сборки), настронных в SonarQube: если код не удовлетворяет требованиям Quality Gate, сборка будет считаться неудавшейся. Таким образом, разработчики SonarQube стремятся сделать свой продукт максимально открытым и позволить командам разработчиков интегрировать SonarQube в их окружение.
Для каких же проектов и команд целесообразно внедрять SonarQube? Я считаю, что для относительно короткосрочных проектов (не более 2 — 3 месяцев), которыми занимаются небольшие команды (не более 5 человек), инвестиции во внедрение SonarQube в процесс разработки могут не оправдаться. Как правило, такие проекты не требуют больших затрат на поддержку продукта. Для таких проектов я бы рекомендовал ограничиться отдельными инструментами для контроля состояния кода проекта: статический анализатор, контроль покрытия кода тестами, соответствие стандартам кодирования и т.д., которые команда привыкла использовать.
На крупных проектах, требующих значительных ресурсов, с продолжительным жизненным циклом, внедрение платформы SonarQube в процесс разработки оправдано. Причем внедрение SonarQube может принести пользу на любой стадии развития проекта. Оптимальная, на мой взгляд, стратегия — это внедрение SonarQube на ранних этапах цикла разработки, что позволит команде с самого начала анализировать отчеты о контроле качества и быть уверенными в том, что соблюдаются заданные стандарты качества кода. Внедрение SonarQube на более поздних этапах разработки потенциально может потребовать больших затрат на улучшение качества кода. Так, например, может выясниться, что статический анализ обнаружил большое количество потенциальных ошибок, присутствует большой объем технического долга, код не покрыт тестами, публичные API не документированы и т.д. Тем не менее, выявление рисков продукта на любой стадии жизненного цикла позволяет правильно отреагировать на эти риски и спланировать действия по их минимизации.
Например, команда может договориться, что при изменении какого-то участка кода в рамках разработки новой функциональности будет ликвидирован весь технический долг в этом коде. Инвестиции в устранение найденных недостатков позволят в дальнейшем снизить стоимость поддержки продукта и разработки нового функционала. Также, если продукт давно присутствует на рынке, и, несмотря на то, что инспекция качества кода выявила большое количество проблем, поведение в продукционной среде достаточно стабильно и в текущий момент времени нет достаточных ресурсов для улучшения качества кодовой базы, можно отложить эту инвестицию. SonarQube предоставляет возможность сфокусироваться на проблемах, появившихся в новом коде. Эта функциональность похожа на функциональность массового подавления сообщений в PVS-Studio.
Как SonarQube помогает оценить качество кода
В основе модели качества SonarQube лежит реализация методологии SQALE (Software Quality Assessment based on Lifecycle Expectations) с определенными дополнениями. Как известно, методология SQALE фокусируется в основном на сложности поддержки кода (maintainability) и не учитывает риски проекта. Например, если сегодня в проекте обнаружилась критическая проблема безопасности, строгое следование методологии SQALE обязывает вас устранить все уже существующие проблемы с надежностью (reliability), возможностью изменений (changeability), тестируемостью (testability) и т.д., и только затем вернуться к новой критической проблеме. На самом деле, если потенциальные проблемы существуют в коде давно и не проявляют себя в виде пользовательских баг-репортов, гораздо важнее сфокусироваться на исправлении новых багов.
С учетом этого, разработчики SonarQube модифицировали модель качества, основанную на SQALE, чтобы акцентировать внимание на следующих важных моментах:
PVS-Studio и SonarQube
Для импорта результатов анализа в SonarQube мы разработали плагин sonar-pvs-studio-plugin. Использование плагина позволяет добавлять сообщения, найденные анализатором PVS-Studio, в базу сообщений сервера SonarQube. Плагин содержит репозиторий с описанием диагностик, которые выполняет наш статический анализатор. После того, как вы добавите наш плагин в SonarQube, вы увидите репозиторий с названием PVS-Studio для языков C, C++ и C#:
Диагностические сообщения PVS-Studio в репозитории плагина сопровождаются подробными описаниями ошибок с примерами кода и рекомендациями по устранению проблемы:
После статического анализа кода проекта и импорта результатов в SonarQube, с помощью фильтров вы можете, например, выбрать все неисправленные проблемы, найденные PVS-Studio:
Чтобы добавить результаты анализа PVS-Studio в SonarQube, достаточно установить плагин sonar-pvs-studio-plugin, добавить диагностики PVS-Studio из репозитория плагина в Quality Profile и передать путь до файла отчета PVS-Studio в свойстве sonar.pvs-studio.reportPath при запуске сканера SonarQube.
Для анализа проектов MSBuild разработчики SonarQube рекомендуют использовать SonarQube Scanner for MSBuild. Этот сканер представляет из себя обертку над стандартным сканером SonarQube и облегчает процесс создания конфигурационного файла сканера sonar-project.properties, автоматически добавляя в него модули (проекты в решении) и записывая пути до исходных файлов, которые необходимо проанализировать.
Однако мы столкнулись с важными с нашей точки зрения ограничениями сканера SonarQube Scanner for MSBuild.
Во-вторых, SonarQube Scanner for MSBuild не добавляет для анализа исходные файлы, расположенные выше по дереву каталогов, чем каталог, в котором находится проектный файл. Сообщения для таких файлов будут также отсутствовать в SonarQube.
Исходя из этих ограничений, для импорта результатов анализа PVS-Studio мы рекомендуем использовать стандартный сканер SonarQube. Использование этого сканера предполагает создание конфигурационного файла sonar-project.properties вручную. Использование и настройка сканера описаны в статье Analyzing with SonarQube Scanner.
По умолчанию, сканер SonarQube индексирует исходные файлы для анализа, расположенные по дереву каталогов ниже, чем файл решения (.sln) либо проекта (.vcxproj/.csproj). Для анализа проектов со сложной структурой, где исходные файлы могут находиться выше по дереву каталогов, чем файл решения или проекта, в свойстве sonar.projectBaseDir нужно указать наивысший общий каталог для всех исходных файлов (в крайнем случае, это может быть корень диска), и в свойстве sonar.sources затем перечислить директории, в которых следует искать исходные файлы для анализа (либо полные пути до исходных файлов).
Процесс добавления путей до исходных файлов в свойство sonar.sources для больших проектов может быть достаточно трудоемким, а с учетом всех подключаемых заголовочных файлов — и нетривиальным. Чтобы облегчить эту задачу, мы реализовали специальный режим работы нашего анализатора, позволяющий автоматически создавать конфигурационные файлы для сканера SonarQube.
При разработке нашего статического анализатора мы фокусируемся на поиске ошибок в коде, и не поддерживаем поиск потенциальных уязвимостей и code smells, поэтому при использовании нашего плагина для SonarQube метрики Security и Maintainability не будут заполнены. Также следует отметить, что в текущей версии нашего плагина не реализовано вычисление Duplications, Complexity и Documentation.
Заключение
В этом обзоре я попытался показать, как SonarQube позволяет внедрить и применять практики контроля качества кода на основе метрик. Как сказал Питер Друкер (или, возможно, это был Уильям Деминг): if you can’t measure it, you can’t improve it. Регулярный сбор метрик кода, анализ их изменения с течением времени позволяет обнаруживать, что технический долг накапливается, поддерживаемость кода снижается, что приводит к увеличению стоимости разработки нового функционала и повышению рисков, связанных с поставкой новых версий продукта. Приведу цитату из книги «Программист-прагматик. Путь от подмастерья к мастеру» Эндрю Ханта и Дэвида Томаса:
«Не оставляйте «разбитые окна» (неудачные конструкции, неверные решения или некачественный текст программы) без внимания. Как только их обнаружите, чините сразу. Если нет времени на надлежащий ремонт, забейте окно досками. Наверняка вы сможете закомментировать ошибочный фрагмент или вывести на экран сообщение «В стадии разработки», или использовать фиктивные данные. Необходимо предпринять хотя бы малейшее действие, чтобы предотвратить дальнейшее разрушение, и показать, что вы контролируете ситуацию.
Мы видели, как безошибочные, функциональные системы быстро портились, как только окна начали разбиваться. Существуют и другие факторы, которые вносят свой вклад в порчу программ, и мы коснемся некоторых из них далее, но небрежность ускоряет порчу быстрее, чем любой другой фактор.
Вы можете подумать, что ни у кого не будет времени обойти «разбитые окна» проекта и отремонтировать их. Если вы продолжаете думать подобным образом, тогда вам лучше спланировать приобретение мусорного контейнера или переехать в другой район города. Не давайте энтропии победить себя.«.
Платформа SonarQube позволяет обнаруживать такие «разбитые окна». Используя SonarQube, вы получите доступ к консолидированным отчетам о состоянии кода проекта, смотреть, как это состояние меняется с течением времени, сможете исследовать обнаруженные проблемы методом анализа «сверху вниз», от значения интересующей вас метрики для всего проекта в целом до конкретного участка кода прямо в окне браузера. SonarQube также предоставляет оценку времени, необходимого для устранения проблем в коде. Таким образом, если в вашем проекте накопился большой объем технического долга, вы всегда можете сказать, сколько вам нужно времени для его устранения.
Из интересных и полезных особенностей SonarQube хочу также отметить его широкие возможности для интеграции с другими инструментами, что делает его частью вашего ALM-фреймворка, и возможности расширения сушествующего функционала благодаря использованию сторонних плагинов. И вся эта мощь и удобство доступны под свободной лицензией бесплатно. Если вы используете статический анализатор PVS-Studio, наш плагин позволит вам импортировать результаты анализа в SonarQube, чтобы использовать его возможности для исследования проблем с качеством кода.
Если возможности платформы SonarQube вас заинтересовали, попробуйте ее в своем окружении. Установка SonarQube очень проста и заключается лишь в извлечении файлов дистрибутива из архива и запуске исполняемого файла под вашу операционную систему.
Также вы можете проверить свои проекты, написанные на языках C/C++ или C#, с помощью статического анализатора PVS-Studio.
Полезные ссылки
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Pavel Kusnetsov. Control source code quality using the SonarQube platform.