SonarQube. Проверяем код на качество
SonarQube — платформа для проверки кода на качество по правилам, основанным на соглашениях и стандартах. Поддерживает более 20 различных языков программирования.
Вот здесь можно посмотреть все эти правила.
Хочу поделиться небольшим руководством, как подружить sonarQube, PhpStorm и ваш проект. Все действия описаны для Windows, но все так же настраивается и под другую ОС.
Для начала необходимо скачать демон SonarQube (на данный момент последняя версия 5.1), который запустит сервер и будет хранить данные о ваших тестах. Распакуем его в папку
Затем скачаем плагин для языка программирования, который вы собираетесь проверять (для меня — это плагин PHP) и положим его в папку plugins
Для того, чтобы запустить саму проверку, необходим runner, который мы скачиваем там же и, если необходимо, прописывем его в системных переменных.
Так же необходимо настроить файлы конфигурации тестов. Для этого в корне вашего проекта создадим файл sonar-project.properties со следующим содержанием:
Перед тем, как запускать SonarQube, убедитесь, что на вашей машине стоит JavaVirtualMachine
Переходим в корень проекта и запускам от туда runner
После успешного выполнения появится текст, примерно такого содержания.
Если у вас тест падает, то для меня это было по нескольким причинам:
Неправильно прописанные конфиги. Например, папка, которая указана к проверке не существует
Не хватает памяти для JVM. Решается увеличениeм памяти для нашего демона:
Необходимо в настройках SonarQube
Теперь мы можем посмотреть на результаты теста по адресу:
В результатах можно посмотреть количество и виды ошибок, а так же подробно прочитать о каждой ошибке и примере ее исправления.
Скачаем сам плагин для IDE:
Зайдем в меню, для установки плагинов в PhpStorm: File->settings->plugins->BrowseRepositories
Найдем там SonarQube и установим его.
(Плагин разработан компанией Jetbrains, так что, скорее всего, его поддерживают и другие IDE этой компании).
Настраиваем плагин:
Зайдем в настройки плагина: File->settings->OtherSettings->SonarQube
Для начала настроим сервер, к которму будет обращаться плагин, чтобы получить результаты теста. Для этого кликнем на кнопку add и впишем настройки.
Затем загрузим результаты нашего теста. Для этого кликнем на зеленом плюсике, обновим список проектов кликнув по кнопке download resources, выберем наш проект и добавим его.
Теперь можно проинспектировать код, смотреть какие несоответствия со стандартами были допущены и исправлять их.
Проинспектируем код в PhpStorm: Code->InsectCode->wholeProject:
Надеюсь, моя инструкция кому нибудь пригодится.
SonarQube: за качество кода отвечаем
Mar 19 · 6 min read
Сразу оговорюсь, что в настоящее время основное внимание я уделяю разработкам на JavaScript и, в частности, React, в связи с чем в статье будет встречаться терминология из этой области. Однако, учитывая мой богатый опыт в сфере программирования, настоятельно рекомендую ознакомиться с материалом, даже если вы предпочитаете другие фреймворки и языки, поскольку SonarQube поддерживает многие из них.
Большинство разработчиков, и мы с вами не ис к лючение, пишут, как им иногда кажется, совершенный код. Некоторые уже используют в IDE инструменты статического анализа, такие как ESLint, которые выявляют возможности улучшения каких-то частей кода в процессе его написания. Практика хорошая, и не стоит от нее отказываться.
Но здесь и сейчас будет представлен инструмент для повышения качества кода, выводящий этот процесс на новый уровень — SonarQube. Вы узнаете:
В статье будет рассмотрена открытая версия для сообщества. SonarQube невероятно полезный инструмент, так что я с радостью поделюсь своими знаниями о нем.
Что такое SonarQube?
Иначе говоря, она не выполняет код, а лишь просматривает его. Причем, можете мне поверить, делает это очень тщательно. Неудивительно, что у SonarQube довольно внушительный список клиентов и репутация одного из востребованных инструментов статического анализа кода.
Завершив сканирование кода, о чем будет рассказано далее, SonarQube формирует отчет, который можно посмотреть в GUI через браузер. Все обнаруженные проблемы представляют собой “интерактивные тикеты”, позволяющие писать к ним комментарии, делегировать их другим пользователям, открывать или закрывать и т. д.
К подробному описанию проблемы сразу же прилагается соответствующий код.
Можно поймать себя на мысли, что такие распространенные инструменты, как ESLint, делают то же самое непосредственно в процессе написания кода, в чем я, однако, не уверен. Интуиция мне подсказывает, что SonarQube обеспечивает намного более высокое качество по широкому спектру тем, таких как код с запашком, ошибки и уязвимости системы безопасности.
Речь идет не просто об отчете, а о сложно структурированном “живом” наборе данных, который осуществляет постоянный контроль за проектом и сообщает его владельцам о текущем состоянии качества. При этом он позволяет другим участникам проекта совместно работать над этим состоянием. Проблемы можно обсуждать и делегировать, что весьма способствует сотрудничеству.
По моему мнению, именно в возможности совместной работы состоит самое существенное преимущество SonarQube перед такими инструментами, как ESLint, используя который, “разработчик решает проблему собственными силами”.
Установка SonarQube (открытая версия для сообщества)
Установка сервера SonarQube (приложение Java) не представляет сложности. Вы можете:
Самый простой способ — запустить Docker-контейнер. Из документации вы узнаете, как скачать ZIP-файл и локально его распаковать.
Перед выполнением следующей команды убедитесь, что Docker у вас уже локально установлен:
Обратите внимание, что эта команда запустит SonarQube, но в момент удаления контейнера все данные будут потеряны. Можно выполнить ее ради эксперимента. Если же вы решите продолжить работу с SonarQube, советую закрыть этот контейнер и настроить тома данных. Имеются в виду каталоги, которые находятся в локальном компьютере и сохраняются в случае закрытия или обновления Docker-контейнера. Документация содержит пошаговую инструкцию к этому процессу.
В рамках данной статьи для запуска SonarQube будет достаточно вышеуказанной команды.
Создание нового проекта
Авторизуйтесь с помощью предустановленных учетных данных ( admin : admin ) и создайте новый проект.
Запомните ключ проекта и токен, поскольку они нам в дальнейшем понадобятся.
Первое сканирование проекта
В корневом каталоге проекта создайте файл sonar-project.properties со следующим содержимым:
Первая строка кода содержит ключ, полученный при создании проекта SonarQube в GUI.
Настало время просканировать файлы. В корневом каталоге проекта выполните данную команду:
Работа сканера займет несколько секунд, после чего в GUI в браузере вы сможете изучить отчет. Если проект содержит высоко качественный код, то результаты будут представлены в следующем виде:
При наличии в коде ошибок, уязвимостей, проблемных зон в системе безопасности, запашков или дублированных строк отчет примет совершенно другой вид. Поскольку GUI прост и понятен, я не буду вдаваться в детали.
Дополнительная информация
При настройке и применении SonarQube также следует знать следующее:
Заключение
Как видите, проще простого настроить SonarQube и поэкспериментировать с ним. Без особого труда вы также разберетесь в принципах составления отчетов и в работе GUI. Так что нет ничего, что помешало бы вам начать его использовать.
Вам доступна быстро настраиваемая открытая версия для сообщества, благодаря которой вы получаете высококачественный код.
Этот инструмент отлично подходит для командного взаимодействия, поскольку позволяет всем участникам совместно работать над качеством кода в проектах. SonarQube можно интегрировать в конвейеры и веб-сайты, например GitHub, а GitLab поддерживает его по умолчанию.
SonarQube и IntelliJ IDEA: правильная интеграция
SonarQube — отличный инструмент для внедрения статического анализа кода в процесс разработки ПО. Он поддерживает как используемую у нас в компании Java, так и большое количество других языков программирования.
На данный момент этот инструмент плотно вошёл в нашу жизнь, следя за единым стилем кода и уберегая от самых разных видов ошибок. Поиск ошибок происходит при сборке на CI или перед принятием pull request в версионное хранилище. Все найденные ошибки отображаются в Web-интерфейсе, где можно изучать их и управлять ими.
Однако беда в том, что удобный Web-интерфейс не означает удобство по устранению найденных замечаний в коде проекта. Для того, чтобы внести исправление, приходится сначала смотреть, в каком именно файле это замечание обнаружено, потом открывать этот файл и только затем вносить исправление. Также это приводит к тому, что разработчик узнает о проблеме с очень большим отставанием (иногда анализ в SonarQube может занимать десятки минут), что не способствует поддержанию чистоты кода.
Для того, чтобы облегчить жизнь разработчикам нашей компании, использующим IntelliJ IDEA, я составил инструкцию. А в дальнейшем понял, что она может быть полезной более широкому кругу специалистов, и решил выложить её в публичный доступ.
Так как моя статья — первая в корпоративном блоге НПО «Криста», напишу несколько слов о своей компании.
Поле нашей деятельности — информационные технологии для государственного и муниципального управления. Мы озабочены результативностью государственных реформ, эффективностью деятельности органов власти, качеством государственных услуг, прозрачностью финансовой отчётности, открытостью бюджетных данных для населения и т. д.
История компании началась в Рыбинске. Туристы иногда посещают наш город, путешествуя на теплоходах по Волге. Ищите его на карте рядом с Рыбинским водохранилищем. Современная география наших производственных центров, филиалов и представительств значительно шире, но главный центр НПО «Криста» по-прежнему находится в Рыбинске.
Для начала посмотрим, какие инспекции вообще поддерживает SonarQube. Прежде всего, это собственные инспекции, идущие в поставке по умолчанию. Но, помимо этого, есть ещё и плагины для интеграции нескольких сторонних анализаторов:
Каждую отдельную инспекцию можно настраивать индивидуально, а также объединять их в профили, позволяя иметь единый набор инспекций для всего предприятия. Так, у нас в основном профиле активировано более 1200 разных инспекций. Понятно, что ни один человек не в состоянии удержать столько правил в голове, а значит, после каждого этапа написания кода следует этап правки замечаний от SonarQube. И чем короче этот этап, тем он менее болезненный для разработчика. Так как же его можно упростить?
Для решения этой проблемы различные IDE имеют плагины, позволяющие вынимать информацию с сервера SonarQube и отображать её прямо в редакторе кода. В случае с IntelliJ IDEA это, прежде всего, SonarLint — официальный плагин от разработчиков самого SonarQube. Он берёт с сервера только профиль с настройками активных инспекций, а сам анализ делает налету прямо в IDE. Это значительно повышает качество разработки, позволяя сразу видеть все новые замечания и оперативно их исправлять. Но тут есть ложка дёгтя. SonarLint работает исключительно с собственными инспекциями SonarQube, полностью игнорируя все остальные инспекции. Замечаний ни от FindBugs, ни от CheckStyle или PMD вы не увидите. А ведь там может содержаться весьма много ценной информации.
Но не стоит отчаиваться: сервер SonarQube умеет экспортировать настройки для всех анализаторов, а значит, имеется возможность настроить штатные плагины IDEA так, чтобы они выдавали результат, эквивалентный серверному.
Давайте разберёмся с этими настройками по порядку.
Настройка SonarLint
Тут нет никаких хитростей. Идём в настройки IDEA и в разделе Plugins находим плагин SonarLint и устанавливаем его.
Изначально плагин использует настройки инспекций по умолчанию. Теперь можно перейти в окно плагина и сконфигурировать подключение к серверу SonarQube. Так как лучше один раз увидеть, чем сто раз прочитать, то просто приведу серию скриншотов последовательности настройки. Здесь и далее красным будут обведены места, требующие к себе внимания. Это или поля для заполнения, или кнопки, которые требуется нажать, или флаги, которые требуется привести к указанному виду:
Главное — не забыть нажать Update binding после добавления нового сервера, чтобы плагин загрузил профиль с настройками. Эту кнопку придётся нажимать всякий раз, когда профиль изменится на сервере (добавили/удалили инспекции, изменили их настройки).
Если у вас подключено несколько модулей в один проект IDEA, то в настройках придётся переключаться на конкретный модуль всякий раз, когда вам его надо будет проанализировать на предмет замечаний. Это не очень удобно, но так есть.
Список замечаний будет обновляться автоматически в фоновом режиме всякий раз, когда открывается новый файл или в этот файл вносятся изменения. Если такое поведение нежелательно, то его можно отключить там же, в настройках плагина.
Пример того, как выглядит работа с SonarLint можно увидеть ниже (картинка кликабельна):
Бывают ситуации, когда SonarLint по какой-либо причине отказывается работать. В таком случае в окне самого SonarLint можно перейти на вкладку логов и посмотреть, что случилось. Но, к сожалению, информация в этом логе не всегда понятна и достаточна.
Например, после последнего релиза IntelliJ IDEA (2019.2) у меня перестало работать вот с такой ошибкой:
Очень информативно… И самостоятельно догадаться, как получить больше информации, не получилось.
Ситуацию спас F.A.Q. на сайте SonarQube. Оказывается, в окне SonarLint в IDEA можно изменять уровень логирования ошибок:
Если отметить выбранные пункты, то начнёт появляться более подробный лог, из которого уже можно понять, что происходит:
Ага! Теперь ошибка появилась, и стало понятно, что происходит.
По сути, случился неприятный конфликт версий. Наши приложения до сих пор используют Java 8 и проверяются на SonarQube 7.1. При этом весь производственный процесс завязан на возможности SonarQube анализировать разницу в ошибках между основной веткой разработки и Pull Request’ом.
Но самое неприятное, что с версии SonarQube 7.2 эта функция стала платной, из-за чего мы до сих пор не обновились до последней версии. А поддержка Java 11 была реализована только в SonarQube 7.3.
Ещё одним важным моментом является то, что плагин SonarLint при анализе кода в обязательном порядке компилирует исходники с помощью той JRE, на которой запущена IntelliJ IDEA. Пока IDEA работала на Java 8, у нас было всё хорошо. Но вот когда она в версии 2019.2 перешла на использование Java 11, то всё посыпалось, т. к. по факту происходит компиляция в байткод от Java 11 (class file major version 55), а анализируется той версией анализатора, которая установлена на сервере, т. е. не поддерживающей этот формат байткода. И это известная проблема.
Видимо, придётся срочно искать пути обновления SonarQube до последней версии. Возможно, с использованием стороннего плагина sonarqube-community-branch-plugin, предлагающего необходимые нам функции.
Выгрузка настроек анализаторов из SonarQube
Для каждого из плагинов, кроме SonarLint, необходимы свои файлы настроек, каждый — в собственном формате. К счастью, SonarQube умеет выгружать эти файлы. Они находятся в окне настройки профиля анализа.
Для того, чтобы туда попасть, необходимо в Web-интерфейсе сервера SonarQube перейти в раздел Quality Profile и выбрать тот профиль, который используется для анализа проекта:
На открывшейся странице появится раздел, предоставляющий ссылки для экспорта настроек под каждый из анализаторов:
Настройка CheckStyle
В IDEA плагин называется CheckStyle-IDEA. Это, пожалуй, самый беспроблемный с точки зрения использования плагин, т. к. позволяет загрузить настройки прямо по URL и не требует переключения между модулями, как SonarLint.
И указать источник конфигурации:
Также не забываем отметить вновь добавленную конфигурацию как активную в таблице окна настроек.
Всё, теперь можно переходить в окно CheckStyle и запускать анализ (верхняя отмеченная кнопка):
В случае, если профиль на сервере SonarQube поменялся, необходимо обновить настройки путём нажатия соответствующей кнопки в том же окне (нижняя отмеченная кнопка).
В случае ошибки «The Checkstyle rules file could not be parsed», а именно «SuppressionCommentFilter is not allowed as a child in Checker», нужно понизить версию Checkstyle в настройках плагина, которая используется на сервере SonarQube. Соответствие версий можно посмотреть в таблице в описании плагина Checkstyle для SonarQube.
Настройка FindBugs
В IDEA плагин называется FindBugs-IDEA. В отличие от предыдущих рассмотренных плагинов, этот не умеет брать настройки напрямую с сервера и требует наличия локального файла.
Плагин готов к работе. В его окне можно запустить анализ как отдельного файла, так и всего проекта или любого другого скопа на выбор:
Важное замечание 2: если настройки на сервере SonarQube изменились, то необходимо выгрузить заново на диск.
Важное замечание 3: к огромному сожалению, развитие данного плагина застопорилось после того, как разработка самого FindBugs была переведена в его форк SpotBugs. В багтреккере JetBrains есть тикет на эту тему. Так что если вы наравне с нами захотите полноценную поддержку всех замечаний SonarQube прямо у себя, в любимой IDE, то можно проголосовать за этот тикет. Может, телега-таки сдвинется с места.
Настройка PMD
В IDEA плагин называется PMDPlugin. Аналогично с FindBugs, этот плагин требует наличия файла настроек на диске. Для конфигурирования идём в настройки IDEA и добавляем файл, выгруженный из SonarQube:
Имя файла играет важную роль, т. к. в дальнейшем оно будет использовано плагином для формирования соответствующего пункта меню для запуска анализа.
Также в соседней вкладе необходимо указать ту версию Java, которую использует проект (ну, и кодировку заодно):
Теперь можно запустить анализ текущего файла, воспользовавшись контекстным меню:
Важное замечание 1: PMD можно также запустить через главное меню, но делать это не рекомендуется, т. к. в этом случае проверке подвергнется не один файл, а весь открытый в IDE проект. Это может занять много времени и значительно перегрузить систему.
Важное замечание 2: как и FindBugs, PMD требует наличия файла конфигурации на диске. Следовательно, необходимо обновлять его каждый раз, когда настройки профиля SonarQube меняются.
Заключение
Резюмируя сказанное, отмечу следующее. Несмотря на то, что для отслеживания замечаний приходится управлять настройками целых 4-х плагинов, это всё же лучше, чем каждый раз ждать, пока результаты редактирования появятся на сервере SonarQube, и позволяет сразу коммитить более чистый код.
Надеюсь, что изложенная здесь информация поможет кому-нибудь легче подружиться со статическими анализаторами вообще и с SonarQube в частности.
Так же хочу поблагодарить коллег, помогавших мне с написанием и поддержкой актуальности этой статьи: Дмитрия Зимичева, Юрия Крупина и Артёма Ганева.
DATAENGINER
SonarQube — универсальный инструмент для статического анализа кода, который стал более или менее отраслевым стандартом. С SonarQube также намного проще сохранять код чистым, простым и легким для чтения.
Вы когда-нибудь слышали о SonarQube? Вы хотите знать, что это такое? А как им пользоваться? И его преимущества для производственной фазы разработки программного обеспечения. Тогда вы попали в нужное место; в этом руководстве по SonarQube я расскажу вам о каждом аспекте SonarQube.
Что такое SonarQube?
onarQube — это платформа с открытым исходным кодом, разработанная SonarSource для непрерывной проверки качества кода. Sonar выполняет статический анализ кода, который предоставляет подробный отчет об ошибках, запахах кода, уязвимостях, дублировании кода.
Он поддерживает 25+ основных языков программирования через встроенные наборы правил, а также может быть расширен с помощью различных плагинов.
Преимущества SonarQube
Почему SonarQube?
Разработчики работают в жесткие сроки, чтобы предоставить заказчику необходимый функционал. Это настолько важно для разработчиков, что они часто идут на компромисс с качеством кода, потенциальными ошибками, дублированием кода и плохим распределением сложности.
Кроме того, они, как правило, оставляют неиспользуемые переменные, методы и т. д. В этом сценарии код будет работать желаемым образом.
Как вы думаете, это правильный способ реализации функциональности?
Чтобы избежать этих проблем в коде, разработчики всегда должны следовать хорошей практике кодирования, но иногда невозможно следовать правилам и поддерживать хорошее качество, поскольку может быть много причин.
Чтобы обеспечить непрерывную интеграцию и развертывание кода, разработчикам нужен инструмент, который не только работает один раз, чтобы проверить и сообщить им о проблемах в коде, но также отслеживать и контролировать код для непрерывной проверки качества кода. Чтобы удовлетворить все эти требования, на картинке представлен SonarQube.
Как настроить и использовать плагин sonarqube
В этом разделе объясняются шаги или процедуры по настройке плагина sonarqube для всех основных языков программирования.
Предпосылки:
Единственное предварительное условие для запуска SonarQube — наличие установленной на вашем компьютере Java (Oracle JRE 11 или OpenJDK 11). [ подробности ]
Установите системную переменную PATH: ( https://www.java.com/en/download/help/path.xml ) [https://www.java.com/en/download/help/path.xml]
Примечание. Для анализа кода JavaScript на компьютере, на котором выполняется сканирование, должен быть установлен Node.js> = 8. Если стандартный узел недоступен, вы должны установить для свойства sonar.nodejs.executable абсолютный путь к исполняемому файлу Node.js. [ подробности ]
Загрузки Sonarqube и Sonar Scanner:
Запустите сервер Sonarqube:
Чтобы запустить сервер сонара, откройте cmd или терминал и установите путь к папке bin sonarqube, выберите платформу и выполните следующую команду.
#For Windows(cmd): C:\sonarqube\bin\windows-x86-64>StartSonar.bat
#For other OS (terminal): C:\sonarqube\bin\[OS]>sonar.sh
После успешного запуска сервера сонара войдите в систему на http://localhost:9000 с учетными данными системного администратора (логин = admin, пароль = admin).
Создание и анализ проекта:
После завершения анализа вы можете либо просмотреть предоставленную ссылку, чтобы просмотреть отчет эхолота напрямую [Пример: http: // localhost: 9000 / dashboard? либо перейти в раздел проекта, чтобы просмотреть вновь созданный отчет сонара ваш проект.
Если вы хотите исключить некоторые файлы из анализа (например, тестовые файлы), перейдите в раздел администрирования и перейдите к настройке «Общие», выберите используемый язык программирования и задайте список шаблонов путей к файлам, которые следует исключить из анализа.
Теперь повторно запустите указанную выше команду анализа для обновленного отчета сонара.
Заключение
Цель SonarQube — в первую очередь расширить возможности разработчиков и создать открытое сообщество по вопросам качества и безопасности кода. Я надеюсь, что с помощью этого краткого руководства по sonarqube вы получите базовое представление о функциональных возможностях, и, если вы так считаете, оставьте комментарий и продемонстрируйте свою поддержку.