SonarQube: про объемы, ветки, покрытие кода и интеграцию с Gitlab

26.02.23

Разработка - DevOps и автоматизация разработки

Опыт применения SonarQube в нескольких командах. Плюс некоторые тонкости: уменьшение объемов базы SQ, интеграция, покрытие кода.

Введение

Казалось бы, уже столько всего написано про SonarQube, но все равно есть чем поделиться. В дополнение к докладу "Разветвленная разработка на хранилищах и файлах поставки" на Infostart Event 2022 вашему вниманию предлагается опыт нашего департамента по работе с SQ и организации самого процесса контроля качества кода.

 

Процесс разработки

Наши разработчики имеют индивидуальные хранилища по каждой задаче и работают исключительно с конфигуратором. Хранилища находятся на поддержке от поставки релизных конфигураций. Любое помещение в хранилище разработчика приводит к разбору версии на исходники, помещению в git и запуску проверки SQ. Разработчик самостоятельно контролирует отсутствие замечаний от сонара и передает задачу на дальнейшее code review только после того как все исправлено. Проверяющий обращает внимание лишь на логику функционирования доработки. Рутинная работа остается сонару, а если быть точным BSL Language Server (ведь именно он выполняет проверки, отдавая результат для формирования наверх SQ).

Кроме исправлений по результатам проверки качества кода и code-review разработчик запускает тесты (Vanessa-Automation) на своем хранилище, подтверждая, что уже существующий функционал "не пострадал". При необходимости тесты могут дорабатываться под новые реалии.

 

Проверки перед помещением в хранилище

Поскольку в нашей схеме проверка кода возникает только после помещения его в хранилище, то здесь возникает нежелательная задержка. Сначала хранилище разберется на исходники, затем попадет в git, потом подождем когда завершится работа sonar scanner - пройдет много времени. Минимум 10-20 минут на всё. Далее разработчик должен посмотреть результаты и исправить ошибки, после чего этот цикл повторится. Если бы в конфигуратор можно было подключить sonar lint или проверки как в EDT, то дело пошло бы быстрее. 

Этап "разработка - проверка" мы ускорили при помощи локального BSL Language Server и обертки над ним в виде Phoenix BSL. Эта штука работает с конфигуратором и позволяет по нажатию кнопки вызвать проверку для любого куска кода. Все это практически мгновенно.

Разработчик локально ставит java, устанавливает феникс с нашими готовыми настройками (bsl-language-server.json) как на сонаре и работает как прежде, но регулярно проверяя код локально. Как результат - мы получаем ускорение проверок на порядки. 

Подробный обзор продукта на Инфостарте: infostart.ru/1c/articles/1656631 

 

Покрытие кода тестами

Узнать, насколько полно конфигурации покрыты тестами, можно при помощи замечательного инструмента Coverage41C. Идея в последовательном прогоне тестов в один поток и замерах производительности, которые конвертируются в соответствующие метрики. Покрытый тестами код можно увидеть прямо в исходниках в интерфейсе SQ.

Вот такие красивые картинки можно увидеть по результату.

 

 

Последние строчки могут вводить в заблуждение - количество строк кода, которое осталось покрыть тестами (Lines to cover, 284К) существенно меньше чем количество кода в проекте (LOC - lines of code, 622К). Тут просто - не весь код можно покрыть тестами. На примере ниже полностью покрытая тестом процедура. Как видим, не весь код исполняется, поэтому такая существенная разница (девять против пятнадцати).

 

 

Поскольку тестов у нас много, запуск происходит в один поток, то время выполнения значительно. Поэтому расчет покрытия кода мы запускаем редко. Для хранения метрики мы используем отдельную неудаляемую ветку. А триггерами к запуску расчета является добавление в нашу коллекцию новых тестов.

 

Объем базы на сервере SonarQube

Ветки и PR

В самом начале работы с SQ было понятно, что удобно можно работать только с ветками. Недостаточно проверять только одно релизное хранилище. В community версии из коробки этого нет, но, к счастью, есть свободно распространяемый плагин https://github.com/mc1arke/sonarqube-community-branch-plugin.

Плагин позволяет выполнять проверки для разных веток хранилища, настраивать разные политики сравнения. В результате разработчик может получать отчеты только на свою ветку, что также ускоряет проверку и постанализ.

Важно. Плагин дорабатывается и следует за обновлениями самого сонара. Но никогда не переходите на новую версию SQ, пока не протестируете работу плагина sonarqube-community-branch-plugin на ней. Плагин сторонний, его поддержка и разработка никак не коррелирует по времени с выпуском новых версий сонара. Можно попасть в ситуацию, когда плагин будет адаптирован лишь через месяц-другой. Все это время вы не сможете работать с ветками. В результате придется откатываться. Возможно, болезненно.

После того как наш первый продукт прошел успешное тестирование на нескольких ветках и было принято решение подключить все остальные хранилища (ветки) к сонару, у нас произошел неприятный инцидент. Подключив десяток веток, по которым были сделаны первые проверки, наша база упала с SQL ошибкой по превышению места. SQL Express с 10Гб на базу не выдержал нагрузки. 

Пришлось разобраться в структуре хранения и понять, что именно занимает столько места. Было сделано несколько удивительных открытий. Оказалось, что ветки хранятся в базе целиком (даже дочерние), не смотря на практически полную идентичность. В итоге, если "цена добавления" одной ветки 100Мб, то три - это уже 300Мб. Такой порядок вещей привел нас в растерянность.

К счастью дальнейшие исследования показали, что хранение кода в Pull-request-ах такой проблемы расточительности лишены. В PR хранятся лишь отличия. Поэтому одна релизная ветка и несколько PR (несколько задач) - это 147Мб + 43Мб + 13Мб + 8МБ и т.д. (все зависит от сложности изменений). И это выход.

 

 

В итоге, наша рабочая схема - одна ветка (мастер), к которой есть много MR. Политика "нового кода" - сравнение с мастером (Project settings -> New code -> Define a specific setting for this project -> Reference branch).

Что же еще отъедает объемы и как все это хранится? Вот интересные запросы для исследования (postgresql).

Как посчитать размер ветки/PR:

 
Запрос к postgresql

Что самое тяжелое в базе?

 
Запрос к postgresql

Количество живых метрик

 
Запрос к postgresql

Здесь на нашем примере видно, что уж лучше бы разработчики меньше создавали smell-кода и ошибок - это напрямую влияет на размер хранения. 

 

 

Автоочистка

Для уменьшения объема хранения однозначно рекомендую использовать автоочистку неиспользуемых веток и PR. Например, из коробки стоит автоудаление в 30 дней, после чего ветка/PR будет удалена. В этом нет ничего страшного. Если запустить сканер еще раз, то ветка появиться вновь.

Важно. Очистка не запускается автоматически по истечении заданного интервала. Она отработает только после запуска любой проверки кода. Это значит, что если проверка у вас не каждый день, а, например, раз в неделю, то удаление произойдет на 30-36 день. Странное поведение, но вот так.

 

Интеграция с Gitlab

Поскольку код у нас уже в git, то почему бы туда же не складывать уведомления о результатах проверок?

Из коробки в SonarQube есть декорирование pull request. Очень мощная штука, которая позволяет внутрь PR/MR (merge request) при помощи комментариев сразу весь код разметить и подсветить все проблемы. Т.е. сразу все наглядно, и даже в SQ можно не переходить. Это удобно и довольно стабильно работает при условии, что замечаний к коду практически нет и коммитов тоже мало. А вот если разработка существенная или длительная, и/или ошибок десяток-другой, то gitlab начинает тормозить при выводе страницы MR. В итоге ожидание становится неприемлемым. При этом сам факт комментариев внутри очень интересен, и мы хотели оставить эту возможность. Дело в том, что мы используем MR еще и как точку входа для запуска тестов. Сюда же попадают ссылки о результатах тестирования. 

В сети на тему комментариев из SQ нашелся лишь https://github.com/gabrie-allaigre/sonar-gitlab-plugin 

Очень мощный настраиваемый плагин. Можно настроить комментарии к строкам кода, выключить их вовсе, настроить вывод различных метрик, причем поддерживаются собственные шаблоны. К большому сожалению, на нашем инстансе плагин так и не заработал. Пробовали разные комбинации версий плагина и сонара и все неудачно. Хотя из коробки с демо-сонаром даже на самом gitlab.com это работает. Увы, пришлось продолжить поиски.

В итоге мы пришли к третьему способу - путем интеграции через веб-хук. После того как сонар выполняет проверку, он отправляет данные в сторонний сервис, который формирует строку с результатами и делает post-запрос к api gitlab для публикации. Веб-хук и адрес сервиса настраивается через интерфейс SQ (Project settings - webhooks).

Для проброса любых параметров через себя у сонара есть специальные параметры sonar.analysis.*. Именно они используются для передачи данных об MR и последующем post-запросе. 

Поэтому сам запуск проверок из gitlab выглядит так (.gitlab-ci.yml) 

 
.gitlab-ci.yml

Роль стороннего сервиса выполняет Jenkins, хотя мог быть простейший веб-сервер со скриптом. Сам пайплайн:

 
 Скрипт для Jenkins

Вот так это выглядит в gitlab после завершения проверки:

 

 

Из минусов подхода через веб-хук - это еще одна точка отказа в виде сервиса отправки.

 

Вместо заключения. А надо ли проверять качество кода

С точки зрения решения бизнеса контроль качества кода можно интерпретировать как лишние затраты, поэтому было важно минимизировать "потраченные часы" на это. Оптимизация в нашем случае - это бесшовность, скорость, удобство для всех участников процесса.

Про преимущества проверок. Как не жаль, но львиную долю потраченного времени составляет отладка. Неиспользованные переменные, смешивание алфавита, неработоспособные или бессмысленные условия - это лишь тот минимум причин, с которым встречался каждый при поиске проблем в коде. 

А если добавить сюда более "интеллектуальные" вещи про парность транзакций, соединения с подзапросами - можно предотвратить и более серьезные проблемы производительности.

Следование стандартам разработки и контроль позволяет снизить время на отладку и поиск этих неприятностей. Объективно посчитать выигрыш от использования проверок, увы, не представляется возможным, потому что измерить отладку по невозникшей проблеме нельзя, ибо она была предотвращена. 

Ну и отдельный блок ссылок про это:

 

Благодарности

Спасибо всем авторам и контрибьюторам перечисленных в статье проектов и продуктов! Вы делаете очень нужную работу! Без вашего вклада, энергии и энтузиазма наш мир так и оставался бы грустным и не оптимальным. Ждем ваших новшеств!

 

Ссылки

сонар сонаркуб покрытие размер

См. также

Автоматическое подтверждение легальности обновления базы или как обновить 100 типовых баз 1С за 5 часов

DevOps и автоматизация разработки Обновление 1С Платформа 1С v8.3 Конфигурации 1cv8 1С:Бухгалтерия 3.0 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)

Расширение для конфигураций 1С для автоматического подтверждения легальности обновления и выполнения обработчиков обновления при пакетном автоматическом обновлении большого числа баз 1С. А также сам модуль обработки по автоматическому обновлению баз.

2 стартмани

08.05.2019    24215    54    VPanin56    26    

26

Взаимодействие 1С со сторонними продуктами посредством REST и Golang (middleware). Часть 4 - NoSQL (MongoDB, Redis)

DevOps и автоматизация разработки Бесплатно (free)

Если в ИТ-инфраструктуре есть NoSQL решения, с которыми требуется взаимодействовать из 1С, можем использовать прослойку на Golang в стиле RESTful

21.09.2020    8123    dmitry-irk38    12    

36

Взаимодействие 1С со сторонними продуктами посредством REST и Golang (middleware). Часть 2 - Docker

DevOps и автоматизация разработки Бесплатно (free)

В предыдущей статье мы создали микросервис, сейчас мы поместим его в Docker контейнер. Статья будет иметь практическую направленность в минималистичном стиле

07.09.2020    5719    dmitry-irk38    0    

18

DevOps в команде специалистов 1С или сказ о том, как желтые котики хотели лучше работать…

DevOps и автоматизация разработки Бесплатно (free)

Основные компоненты, на которых строится идея DevOps – это сотрудничество, доверие, инструменты и масштабируемость. И команда специалистов 1С, не подготовленная к соблюдению этих принципов, может столкнуться с проблемами при внедрении DevOps-практик. Как преодолеть эти сложности, и какие выгоды в результате применения DevOps-инструментов может получить компания, на конференции Infostart Event 2019 Inception рассказал руководитель отдела автоматизации предприятий ОП «Синимекс-Воронеж», Эмиль Карапетян.

04.09.2020    13187    amon_ra    2    

26

Управление конфигуратором в режиме агента с помощью python

Инструменты администратора БД Архивирование (backup) DevOps и автоматизация разработки Платформа 1С v8.3 Конфигурации 1cv8 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

Управление конфигуратором 1С:Предприятие в режиме агента. Опыт применения с реализацией на языке python. Результат получен с использованием интерактивной сессии оболочки через invoke_shell().

06.08.2020    3681    Alex10166    2    

23

Как найти неиспользуемый код

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Описание нескольких способов поиска и определения неиспользуемого кода

03.08.2020    7447    Infostart    29    

71

Как поставить качество кода на поток и при этом не разориться? Какие шаги стоит сделать уже завтра, чтобы повысить планку качества?

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

Наличие в 1С-решениях некачественного кода мешает их поддержке и эффективному развитию. Как добиться соблюдения стандартов разработки при написании кода и внедрить бюджетный Code Review с помощью инструментария на основе АПК (Автоматизированной проверки конфигураций) на конференции Infostart Event 2019 Inception рассказал технический руководитель компании Бизнес Лоджик Иван Козлов.

22.06.2020    5971    kozlov.alians    1    

23
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Scorpion4eg 424 28.02.23 09:16 Сейчас в теме
Привет. Спасибо за статью - было полезно.

Дополню, начиная с какой-то версии(у нас сейчас 9.3) появилась нативная интеграция с gitlab.

После этого замечания могут быть добавлены прямо в MR
Прикрепленные файлы:
2. kraynev-navi 647 28.02.23 19:53 Сейчас в теме
(1) Привет!
Мы отказались от штатной как описал в (0), ибо очень тормозило внутри merge-request. У вас это нормально работает?
3. Scorpion4eg 424 28.02.23 19:56 Сейчас в теме
(2) Да, но у нас объемы кода меньше
4. Olenevod 33 05.03.23 14:05 Сейчас в теме
У меня вопрос по поводу места:
Я сам не пробовал, но планировал попробовать.
Не пробовали пойти таким путем, что для SQ делать отдельную репу в которой бы хранились только файлы BSL?
Использовать игнор на файлы и/или удалять все файлы не BSL предварительно.

П.С.
Доклад по разветвленной разработке очень классный. Крутую вещь сделал.
5. nixel 1403 05.03.23 14:23 Сейчас в теме
6. Olenevod 33 06.03.23 11:04 Сейчас в теме
(5) Сразу скажу я в этом деле начинающий.
Но уже есть проблемы с размерами. А тут вроде тема очень схожая.

Я исхожу из того, что ведь сам проект много весит (несколько Гб, допустим 6). Механику работы SQ с Git не знаю и предполагаю, что на машину где крутиться сонар выкачивается весь репозиторий со всеми файлами.
Но машина где крутиться SQ по дисковому пространству маленькая. И хорошо бы чтобы проект весил, например, около 1 Гб. т.к. проектов может быть много.

Буду рад если подскажете, что-то по этой части.
7. nixel 1403 06.03.23 11:14 Сейчас в теме
(6) давайте чуть больше контекста. Вы под SQ подразумеваете сервер SonarQube, на котором хранятся результаты анализа, или сервер, на котором запускается sonar-scanner и запускается сам анализ?
Olenevod; +1 Ответить
8. Olenevod 33 06.03.23 12:09 Сейчас в теме
(7) Думаю и то и другое.
Скажем условно - хочу арендовать сервис где sonar qube уже как-то работает на каких-то серверах (как детально они настроены я не знаю), но надо очень сильно минимизировать потребление дискового пространства занимаемого проектом (хоть на сервере SonarQube хоть на сервере sonar-scanner). Но предполагаю, что на сервере sonar-scanner должны быть только файлы BSL, и получается тут уже заморачиваться не стоит. Но вот, к сожалению, не знаю все ли файлы репозитория там (html, xml и т.д.) или нет.
9. nixel 1403 06.03.23 13:07 Сейчас в теме
(8) для корректного анализа на стороне сонар-сканнера нужны xml файлы. На сервере SQ - нет, но их там и не будет по настройке sonar-project.properties. Но в репе все равно нужны все файлы, разве что cf и часть bin (не все) можно заигнорить
Olenevod; +1 Ответить
10. Olenevod 33 06.03.23 14:40 Сейчас в теме
(9) Большущее спасибо за ценную информацию. Пойду пока думать.
Оставьте свое сообщение