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 после завершения проверки:

 

 

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

 

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

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

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

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

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

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

 

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

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

 

Ссылки

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

См. также

Автотесты для типовых конфигураций ERP Управление предприятием 2 и Комплексная автоматизация 2 (для vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.15.111.

2220 руб.

04.07.2022    6938    26    1    

24

Автотесты для типовых конфигураций Бухгалтерия предприятия КОРП 3.0 и Бухгалтерия предприятия 3.0 (vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.144.49.

1728 руб.

20.01.2022    6711    10    0    

9

Системы контроля версий для 1С-разработчиков.

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9391    78    4    

112

Управление сборкой. Расширение для конфигурации СППР

DevOps и автоматизация разработки Платформа 1С v8.3 Конфигурации 1cv8 1С:Франчайзи, автоматизация бизнеса Платные (руб)

Подсистема «Управление сборкой GLI» предназначена для динамического формирования сборочных линий Gitlab и отслеживания процесса доработок систем на базе1С:Предприятия Позволяет упростить выпуск новых релизов системы, подготовить описание доработок системы. Интегрируется с GitLab API по событиям Push, Merge-request, Pipeline. Уведомляет пользователей о результатах сборки/тестирования сборочных конвейеров через СВ, либо при её недоступности или отсутствию по E-Mail. Поможет при отправке исправлений ошибок в общую базу тестирования, сформирует запросы на слияние в ветку версии только по протестированному и подтверждённому функционалу. Подсистема рассчитана исключительно на клиент - серверную архитектуру тестовых ИБ. Поддерживаемая версии СППР 2.0.4.15, платформа не ниже 8.3.17.1549, 2.0.7.3 / не ниже 8.3.21.1664, начиная с релиза 1.0.4.30 требуется платформа не ниже 8.3.23 рекомендуемый релиз 8.3.23.1997

7000 руб.

26.08.2022    10777    7    5    

30

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

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

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

2 стартмани

08.05.2019    24405    56    VPanin56    26    

27

Результаты ревью кода 1500+ решений каталога Инфостарт: наиболее частые ошибки разработчиков в коде

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

Поделюсь своим опытом аудита кода авторских продуктов с Infostart.ru как одним из элементов применения DevOps-практик внутри Инфостарт. Будет настоящий код, боевые скриншоты, внутренние мемы от команды ИТ-лаборатории Инфостарт и прочее мясо – все, что любят разработчики.

10.04.2024    5723    artbear    80    

76

Ниндзя-код

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

Предлагаю вашему вниманию советы мастеров древности. Программисты прошлого использовали их, чтобы заострить разум тех, кто после них будет поддерживать код. Гуру разработки при найме старательно ищут их применение в тестовых заданиях. Новички иногда используют их ещё лучше, чем матёрые ниндзя. Прочитайте их и решите, кто вы: ниндзя, новичок или, может быть, гуру? (Адаптация статьи "Ниндзя-код" из учебника JavaScript)

01.04.2024    2327    DrAku1a    15    

33

Практическое программирование: когда скорость важнее совершенства

Рефакторинг и качество кода Бесплатно (free)

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

01.04.2024    602    Prepod2003    6    

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

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

После этого замечания могут быть добавлены прямо в MR
Прикрепленные файлы:
2. kraynev-navi 648 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 1408 05.03.23 14:23 Сейчас в теме
6. Olenevod 33 06.03.23 11:04 Сейчас в теме
(5) Сразу скажу я в этом деле начинающий.
Но уже есть проблемы с размерами. А тут вроде тема очень схожая.

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

Буду рад если подскажете, что-то по этой части.
7. nixel 1408 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 1408 06.03.23 13:07 Сейчас в теме
(8) для корректного анализа на стороне сонар-сканнера нужны xml файлы. На сервере SQ - нет, но их там и не будет по настройке sonar-project.properties. Но в репе все равно нужны все файлы, разве что cf и часть bin (не все) можно заигнорить
Olenevod; +1 Ответить
10. Olenevod 33 06.03.23 14:40 Сейчас в теме
(9) Большущее спасибо за ценную информацию. Пойду пока думать.
Оставьте свое сообщение