От экспертов «1С-Рарус»: Jenkins в разработке конфигураций «1С»
От экспертов «1С-Рарус»: Jenkins в разработке конфигураций «1С»

От экспертов «1С-Рарус»: Jenkins в разработке конфигураций «1С»

09.10.2020
46 мин
21883

Автоматизация тестирования конфигураций «1С»

Процессы разработки бизнес-приложений на платформе «1С:Предприятие» со временем усложняются. Кроме того, разработчики занимаются задачами отличными от разработки, которые решать могут только они.

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

Дымовое тестирование — минимальный набор тестов на явные ошибки. «Дымовой тест» обычно выполняется программистом; не проходившую этот тест программу не имеет смысла отдавать на более глубокое тестирование.

Эти процессы часто повторяются на разных этапах жизненного цикла приложения, и, как правило, представляют собой набор рутинных операций, слабо связанных с основной деятельностью разработчика — разработкой новых функций приложения. Возникает естественное желание автоматизировать эти процессы, дабы повысить эффективность команды разработки.

Выбор инструмента —  Jenkins, TeamCity, Bamboo и Travis

В общем виде автоматизация любого процесса сводится к поэтапному выполнению сценариев, имитирующих работу разработчика, с помощью программы-исполнителя. Как раз такие программы-исполнители представлены целым классом программных продуктов automation server (сервер автоматизации).

Выбор сервера автоматизации, в большинстве случаев, не является принципиальным решением, так как основная логика заключается именно в сценариях, поэтому универсального ответа на вопрос «какой сервер автоматизации использовать?» не существует. Более того, сервера взаимозаменяемы, так как решают одну задачу и, соответственно, имеют общие фундаментальные архитектурные шаблоны.

Таким образом критерии выбора сервера автоматизации для наших задач определялись сложившейся инфраструктурой и процессами в команде разработки.

Основными критериями при выборе сервера автоматизации были:

  • Работа под Windows.
    Так как в нашем подразделении сервера и администраторы работают преимущественно с этой операционной системой, это упростит развертывание и сопровождение.
  • Интеграция с git для перехода на EDT в будущем.
  • Распределенная архитектура рабочих процессов.
    Предпочтительно сразу заложить фундамент для масштабирования. Распределенная архитектура, позволяет наращивать пропускную способность системы, увеличивая количество исполнителей. Концепция распределения задач по исполнителям будет описана далее.
  • Хостинг на собственных серверах.

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

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

Jenkins TeamCity Bamboo Travis
ОС Windows, Linux, macOS, any Unix-like Windows, Linux, macOS, Solaris, FreeBSD Windows, Linux, macOS, Solaris Linux, macOS
Поддержка git да да да Только GitHub
Распределенная архитектура да да да да
Документация и поддержка 3 4 4 1
Хостинг Облачный, собственный Собственный Собственный, облако BitBucket Облачный, собственный
Удобство использования 5 4 4 5
Лицензия MIT Проприетарная Проприетарная MIT

С полным списком инструментов можно ознакомиться тут en.wikipedia.org/wiki/
Comparison_of_continuous
_integration_software.

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

Из минусов можно выделить устаревший и не всегда интуитивно понятный пользовательский интерфейс.

Концепция работы Jenkins

Jenkins — это автономное приложение на Java, которое может работать под Windows, Mac OS X и другими Unix-подобными операционными системами.

Jenkins можно запускать как в режиме единого сервера, так и в распределенном режиме, когда существует главный узел (master) и несколько подчиненных узлов (slave). В рамках подчиненного узла может существовать несколько исполнителей (executor), которые непосредственно выполняют поступающие задачи.

Запуск задачи может выполняться пользователем из веб-интерфейса, внешним приложением через http-интерфейс, при возникновении определенных событий (triggers). При завершении задачи, как правило, нужно оповестить ответственного, Jenkins позволяет настроить оповещения (notifications) через различные каналы коммуникаций (почта, мессенджер, http-запрос).

Концепция работы Jenkins

При поступлении задачи Jenkins ставит её в очередь исполнения и пытается найти свободного исполнителя, и если исполнитель найден, то задача передается ему для выполнения.

Основной единицей работы в Jenkins является задача (job), задача содержит в себе ряд этапов (stage), которые состоят из шагов (step). Под задачей подразумевается целостный набор действий, приводящий к получению конечного результата.

Например, в качестве задачи мы получаем файлы сборки для отправки в фирму «1С» при выпуске новых версий типовых отраслевых конфигураций. Этапы и шаги можно настраивать произвольно, в зависимости от поставленной задачи.

Этапы могут быть независимыми и выполняться параллельно на разных свободных исполнителях. Такой подход называется конвейер (pipeline).

Концепция работы Jenkins

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

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

Этапы задачи можно выполнять параллельно на разных исполнителях, если этого требует задача. Jenkins позволяет по-разному описывать этапы и шаги задачи, мы используем два основных способа.

Первый способ: Freestyle project

Основной и наиболее универсальный тип задач в Jenkins — Freestyle project.

Данный тип проектов может использоваться для любых автоматизируемых задач. Это основной способ описания для задач сборки комплектов типовых отраслевых конфигураций. Описание шагов выполняется в пользовательском интерфейсе «накликиванием» различных типов шагов.

В наших сценариях в основном используются шаги с типом «Команда Windows».

Концепция работы Jenkins

Второй способ: Pipeline

Это тип задачи в Jenkins, с помощью которого мы можем описать задачу в виде специального файла (Jenkinsfile).

Такой подход является более гибким в сравнении с Freestyle описанием, так как описание конвейера выполняется на специальном декларативном языке (jenkins.io/doc/book/pipeline/syntax/). Язык предоставляет более широкие возможности, в том числе параллельное распределение этапов задачи на разных исполнителях. Также описание конвейера можно версионировать и централизованно редактировать в git.

Концепция работы Jenkins

Таким образом Jenkins позволяет пошагово выполнять любые приложения командной строки, сценарии операционной системы, а затем получать и агрегировать результат их выполнения. Этот принцип используется для решения задач автоматизации в «1С» разработке.

Кейсы применения Jenkins

Сборка комплектов

Задача сборки и концепция решения

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

Состав материалов в комплекте может различаться для разных продуктов, однако в общем процесс можно разделить на следующие этапы:

  • Взять предыдущие файлы поставки с общего ресурса.
  • Подключиться к хранилищу разработки, создать файлы поставки и обновления на базе предыдущих поставок.
  • Обновить демонстрационную базу текущим файлом поставки.
  • Прогнать дымовые тесты (открытие форм, корректность объединения некоторых объектов).
  • Выгрузить новую версию демонстрационной базы.
  • Подготовить сопроводительные материалы.
  • Собрать комплекты поставки и обновления.
  • Выложить собранные комплекты и материалы.

Для автоматизации выполнения этих операций система «1С:Предприятие» предоставляет интерфейс командной строки (its.1c.ru/db/v838doc/
bookmark/adm/TI000000493). Например, операция создания базы и подключения её к хранилищу для получения последней версии конфигурации выглядит примерно так:

Кейсы применения Jenkins

Здесь выполняются 2 команды и 3 операции: создание базы, подключение к хранилищу и обновление конфигурации базы данных. Команды объединяются символом &&, который прерывает выполнение следующей команды, если код возврата предыдущей был не равен 0. То есть, если базу создать не удалось, подключаться к хранилищу не нужно.

Вторая команда выводит детали процесса обновления в файл report. Сценарий выглядит довольно громоздко, учитывая, что выполняется простейшая операция. А процесс сборки состоит из десятков подобных операций. Более того, после каждой операции желательно проверить код возврата и увидеть содержимое файла report. Изначально мы использовали именно такой подход:

Кейсы применения Jenkins

Конвейер был реализован на базе Freestyle-задачи. Каждый шаг конвейера представлял собой batch-сценарий, в котором последовательно запускался процесс «1С:Предприятия» в разных режимах. Это рабочий сценарий, он справляется с задачей сборки, но такой сценарий довольно громоздкий и кажется избыточным.

Сопровождать такой сценарий трудоемко:

  • Сложно следить за изменениями в шагах и задачах Jenkins при исправлении ошибки или добавлении новых функций.
  • Не все сотрудники команды разработки знакомы с синтаксисом batch- сценариев.

Для упрощения сопровождения подобных сценариев было принято решение использовать OneScript (oscript.io) предоставляющий:

  • Среду исполнения текстовых сценариев на языке «1С».
  • Механизм построения консольных приложений, написанных на языке «1С».

На OneScript было реализовано консольное приложение — autoMate, скрывающее громоздкие конструкции batch-сценариев за сокращенным представлением команд, а также позволяющее настраивать общие параметры окружения сборки для каждой конкретной задачи единообразно.

Приложение позволяет хранить файлы сценариев в файлах на диске, автоматически загружая их при выполнении. Это позволяет редактировать команды приложения отдельно от самого приложения. Например, при вводе в терминале интерпретатора командной строки команды:

auto <ИмяКоманды> <Параметры команды>,

приложение autoMate пытается найти в указанном корневом каталоге файл сценария определяющий команду с именем <ИмяКоманды> и передать управление коду, определенному в этом файле. Параметры командной строки пробрасываются в сценарий:

Кейсы применения Jenkins

auto — имя приложения, зарегистрированное в системе. Можно использовать полное имя autoMate.

В теле процедуры команды, в свою очередь можно использовать любые конструкции языка «1С». Есть встроенный модуль, упрощающий работу с платформой «1С»:

Кейсы применения Jenkins

Для добавления команды достаточно создать процедуру с аннотацией &Команда в любом файле корневого каталога команд. Это возможно сделать без пересборки приложения, так что хранить команды можно в системе контроля версий и обновлять перед исполнением задачи в виде обычных текстовых файлов. Подключение и исполнение таких команд к приложению выполняется «на лету».

Приложение предоставляет объектную модель для встраивания в другие сценарии и набор команд для сборки комплектов, предоставляя возможность встраивания в другие сценарии:

Кейсы применения Jenkins

Команды загруженные в контекст приложения доступны для использования внутри объекта приложения, таким образом можно собирать более сложные сценарии на основе атомарных команд:

Кейсы применения Jenkins

Объединив приложение autoMate с принципом конвейера задачи Jenkins, мы значительно сократили сложность сопровождения сценариев сборки:

Кейсы применения Jenkins

Команды стали короче и понятнее. Конечно, сложность не исчезла, она была скрыта в сценариях на языке «1С».

Использование в виде декларативного описания конвейера, конечно тоже возможно, вот фрагмент файла описания:

Кейсы применения Jenkins

Окружение приложение можно настраивать через специальный файл, содержащий значения переменных окружения:

Кейсы применения Jenkins

Таким образом можно использовать одни сценарии сборки на в разных задачах сборки, настраивая сценарии без их изменения.

Пример работы конвейера сборки

Рассмотрим пошагово процесс настройки и исполнения сценария сборки очередного комплекта сборки. Для упрощения будем использовать задачу со свободной конфигурацией (Freestyle-проект).

Предположим, имеется конфигурация, сборку которой будем настраивать. Разработка конфигурации ведется на хранилище конфигураций, версия платформы 8.3.12.

История хранилища разработки выглядит так:

Кейсы применения Jenkins

Последний собранный комплект имел номер версии 1.0.1.9, необходимо собрать очередной комплект версии 1.0.2.3.

Структура каталога исходных материалов выглядит так:

Кейсы применения Jenkins

Исходные материалы расположены на внутреннем сервере разработки. Рассмотрим настройки файла settings:

Кейсы применения Jenkins

Поскольку сборка будет выполняться на другом сервере все пути к каталогам и файлам являются сетевыми.

Ответственный сотрудник через веб-интерфейс Jenkins стартует процесс сборки, если необходимо указывает некоторые параметры в диалоге:

Кейсы применения Jenkins

Далее Jenkins вызывает команды:

  • Сперва нужно получить служебные файлы в рабочий каталог сервера сборки:

    Кейсы применения Jenkins

  • Далее сформируем переменные окружения для сеанса сборки, это можно сделать с помощью встроенной команды:

    ККейсы применения Jenkins

    Эта команда создает на основании файла настроек batch файл с установкой значений переменных окружения, для исполнения перед последующими шагами сценария.

  • Получаем версии предыдущих поставок, для которых нужно создать файл обновления конфигурации:

    Кейсы применения Jenkins

  • Создаем новую рабочую базу и подключаемся к хранилищу:

    Кейсы применения Jenkins

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

Для примера ниже приведен полный текст команды make-workbase:


#Использовать "../../lib/Помощник"

Перем ПутьДляЗапуска;
Перем ОпцииВызова;

&Команда(
Псевдоним = "make-workbase",
Раздел = "Композитные команды",
Подсказка = 
"	Создание рабочей информационной базы, с получение cf из хранилища или из файла конфигурации
|
|	Опции:
|	 *--commit[-c] - номер закладки хранилища от которой выполняется формирование рабочей базы.
|					 Перегружает переменную среды ```target.repo_commit``` на время вызова
|	 *--file[-f]   - путь к файлу конфиуграции, на основе которого нужно создать базу.
|					 Если параметр указан, он перегружает переменную среды ```srt.cf.path```",

Пример = "auto make-workbase",
СОпциями = Истина,
ИспользуетКонтекстПриложения = Истина
)
Процедура Выполнение(Опции = Неопределено, ПриложениеКоманднойСтроки = Неопределено) Экспорт

	ПутьКПлатформе   = ПолучитьПеременнуюСреды("env.platform.root");
	ВерсияПлатформы  = ПолучитьПеременнуюСреды("env.platform.ver");
	ПутьДляЗапуска   = ОбъединитьПути(ПутьКПлатформе, ВерсияПлатформы, "bin\1cv8.exe");
	Хранилище        = ПолучитьПеременнуюСреды("src.repo.connection");	
	ВерсияХранилища  = ПолучитьПеременнуюСреды("target.repo_commit");

	Если НЕ ЗначениеЗаполнено(ВерсияХранилища) Тогда
		ВерсияХранилища = 0;
	КонецЕсли;

	ВерсияХранилища = Помощник.ОдноИзЗначений(
		Опции,
		"--commit | -c",
		ВерсияХранилища
	);

	ФайлКонфигурации = ПолучитьПеременнуюСреды("src.cf.path");
	ФайлКонфигурации = Помощник.ОдноИзЗначений(
		Опции,
		"--file | -f",
		ФайлКонфигурации
	);

	ЗагрузитьКонфигурациюИзФайла = ЗначениеЗаполнено(ФайлКонфигурации);

	КонвейерКоманд = Новый Массив();
	КонвейерКоманд.Добавить(
		"create-db work.database -f"
	);
	
	Если ЗагрузитьКонфигурациюИзФайла Тогда
		КонвейерКоманд.Добавить(
			СтрШаблон(
				"load-cf work.database ""%1"" -upd",
				ФайлКонфигурации
			)
		);
	Иначе
		КонвейерКоманд.Добавить(
			СтрШаблон(
				"load-repo work.database ""%1"" -rap=src.repo. -c=%2 -upd",
				Хранилище,
				ВерсияХранилища
			)
		);
		
	КонецЕсли;

	ПриложениеКоманднойСтроки.Интерпретировать(
		СтрСоединить(КонвейерКоманд, Символы.ПС)
	);

КонецПроцедуры
  • На базе последней версии хранилища и предыдущих поставок создаем новые файл поставки и файл обновления конфигурации:

    Кейсы применения Jenkins

  • После чего загружаем и обновляем демонстрационную базу:

    Кейсы применения Jenkins

    Концепция понятна, каждую команду рассматривать не станем.

  • Последним шагом размещаем итоговые материалы на внутреннем сервере и Jenkins отправляет оповещение на почту ответственному.

В веб-интерфейсе Jenkins всегда можно увидеть статус выполняемого этапа и шага:

Концепция работы Jenkins

Таким образом была решена задача автоматизации сборок при выпуске очередных релизов типовых конфигураций.

Запуск автоматических тестов

В данном разделе мы не стремимся рассмотреть технологии тестирования, ограничиваясь демонстрацией взаимодействия с сервером автоматизации.

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

  • актуализация состава тестов;
  • развертывание информационной базы для тестирования;
  • выполнение тестовых сценариев;
  • подготовка отчета по результатам тестирования.

Для упрощения жизни тестировщикам и разработчикам эти операции мы будем автоматизировать. Рассмотрим сценарий тестирования консистентности ролей в «Альфа-Авто: Автосалон+Автосервис+Автозапчасти Корп, редакция 6».

При разработке конфигурации постоянно приходится проверять, правильно ли настроены роли, отключено ли интерактивное удаление, назначены RLS и нет ли ролей, дающих доступ к избыточно большому количеству объектов.

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

Для реализации тестов использовали продукт Vanessa-ADD. Следует заметить, что существует много продуктов такого класса. Например Vanessa-Automation, Tester, 1С:Сценарное тестирование. Причиной выбора продукта Vanessa-ADD явилось то, что он первым попался в руки специалиста и был получен в короткое время результат. Для реализации проверки консистентности ролей потребовались только юнит-тесты, так как нужно было только программное взаимодействие с конфигурацией.

Юнит-тестирование — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы, наборы из одного или более программных модулей вместе с соответствующими управляющими данными, процедурами использования и обработки. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже протестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.

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

В методе ЗаполнитьНаборТестов() обработки-теста необходимо перечислить список имен экспортных процедур из этой же обработки-теста. Эти процедуры становятся шагами тестового сценария, которые будут вызваны при исполнении тестовой обработки. Если при выполнении шагов не возникло ошибок/исключений, тест считается пройденным, иначе проваленным.

Запуск автоматических тестов

Роли разбили на группы по метаданным и на каждую из групп реализовали обработку-тест. А сами обработки сохранили в git для версионирования и отслеживания истории изменения. Получился такой набор обработок:

Запуск автоматических тестов

Данные тесты можно выполнять автоматически и вручную. Ручной запуск обычно используют для процесса отладки. Загруженные в исполнитель тесты выглядят следующим образом:

Запуск автоматических тестов

Реализация конвейера тестирования

Конвейер был реализован на базе Freestyle-задачи. Для взаимодействия с «1С:Предприятием» использовали интерфейс командной строки.

Запуск был настроен по расписанию каждую ночь в пять утра. Для этого в параметре задачи «Запускать периодически» настроим расписание запуска в формате cron 0 5 * * *.

Формат cron — пять чисел, разделенных пробелом или табом в порядке:
Минуты (0–59) Часы (0–23) День месяца (1–31) Месяц (1–12) День недели (0–7)
Где:
*  — Любое значение

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

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

Запуск автоматических тестов

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

Запуск автоматических тестов

Для первого старта конфигурации используется не стандартный интерфейс командной строки «1С: Предприятие», а библиотека на onescript vanessa-runner.

Библиотека vanessa-runner (github.com/vanessa-opensource/vanessa-runner) — это обёртка над интерфейсом командной строки «1С:Предприятие», добавляющая ряд удобств в процесс работы с запуском пакетных команд «1С».

Например, нет необходимости указывать полный путь к исполняемому файлу «1С», достаточно указать версию.

Выполняем тесты:

Запуск автоматических тестов

Интересными в команде являются только последние строки с параметрами запуска исполнителя тестов:

  • xddRun — описание источника тестов. Возможно указать файл обработки или каталог с обработками как в примере.
  • xddReport — описание формата отчета о тестировании и путь для сохранения отчета. Используется отчет в формате Allure2 (docs.qameta.io/allure/).
  • xddShotdown — закрывать «1С:Предприятие» после выполнения тестов.

Для работы с Allure2 в Jenkins существует плагин Allure (plugins.jenkins.io/allure-jenkins-plugin/), который необходим для просмотра отчета в удобном виде:

Запуск автоматических тестов

Запуск автоматических тестов

Финальным штрихом стала настройка рассылки почтовых уведомлений ответственному сотруднику о проваленном тестировании. А он в дальнейшем выполняет исправлении или делегирует его коллегам. Это встроенный в Jenkins шаг после сборки:

Запуск автоматических тестов

Проверка качества кодовой базы

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

Для статического анализа конфигураций мы используем связку инструментов SonarQube и Автоматизированная проверка конфигураций.

В целом процесс выглядит так:

  • Пользователь помещает изменения в хранилище.
  • 1C:ГитКонвертер:
    • выполняет выгрузку xml файлы;
    • выполняет коммиты в локальный  каталог git;
    • отправляет изменения на сервер.
  • По расписанию стартует конвейер на сервере сборок.
    Как правило это производится в момент, когда команда разработки не вносит изменений.
  • Jenkins запускает АПК на проверку конфигурации.
    По окончанию проверки АПК, предоставляется отчет об обнаруженных ошибках.
  • Jenkins передает отчет вместе с исходниками в SonarScanner.
  • SonarScanner выполняет анализ исходников и загрузку результатов на сервер.
  • На утро разработчик видит перечень допущенных им ошибок и может приступить к исправлению.

Проверка качества кодовой базы

В данной схеме Jenkins занимает место посредника / агрегатора между инструментами. Но кроме этого он решает еще одну важнейшую задачу масштабирования. Статический анализ конфигурации может использовать значительные ресурсы сервера.

Например, анализ ERP на 12 ядрах и 16 Гб оперативной памяти занимает около 20 минут в сонар сканере, а анализ ее же в АПК в тех же условиях может занять около 2 часов. Чтобы успеть за одну ночь прогнать проверки всех наших конфигураций необходимо распределять нагрузку по нескольким серверам. Горизонтальное масштабирование реализовали за счет возможности Jenkins запускаться в распределенном режиме:

Концепция работы Jenkins

Перед реализацией, выполнив исследование, обнаружили плагин для работы с SonarQube:

Проверка качества кодовой базы

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

В настройках плагина описываем параметры доступа к серверу SonarQube:

Проверка качества кодовой базы

Плагин предоставляет интерфейс для работы с SonarScanner из задачи:

Проверка качества кодовой базы

Реализация конвейера проверки качества кода

Настраиваем работу ГитКонвертера так, чтобы исходники конфигурации оказались на сервере, используемом для запуска задачи.

Так как задача в Jenkins выглядит почти одинаково и отличается только рядом параметров, для удобства копирования выбрали вид задачи Pipeline.

На самый верх скрипта вынесли изменяемые параметры:

Проверка качества кодовой базы

  • SRC_BASE_DIR — путь к каталогу с исходными файлами.
  • PROJECT_KEY — ключ проекта в АПК и SonarQube.
  • PROJECT_NAME — имя проекта на русском языке.
  • ACC_INSTANCE — строка подключения к АПК.
  • V8_VERSION — версия на которой крутиться АПК.

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

Метки задаются при создании агента:

Проверка качества кодовой базы

Также можно указать параметры самой задачи в Jenkins. Например, сбросить через 8 часов, если задача не завершиться и хранить информацию только о последних 10 сборках.

Процедура запуска сканнера с передачей в него результатов анализа в АПК занимает всего несколько строк:

Проверка качества кодовой базы

После выполнения проверки результат отображается в информации о задаче Jenkins и есть возможность перейти к проекту в SonarQube.

Проверка качества кодовой базы

Так зачем нужен Jenkins в разработке «1С»?

Что же мы увидели в результате прочтения статьи. Во-первых, что существуют рутинные операции, связанные с разработкой продуктов на базе «1С». Во-вторых, что качественное исполнение таких операцией вручную может приводить к ошибкам сборки комплектов, некачественному функционированию и другим не очень приятным вещам.

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

Интересующиеся проверкой качества кода могут посмотреть доклад Эдуарда Иванова с 1C-RarusTechDay 2020 «Инструменты проверки качества кода» здесь.

Вы читаете статью из рубрики:
От экспертов «1С-Рарус»

Есть вопросы по статье? Задайте их нам!

Рассылка «Новости компании»: узнавайте о новых продуктах, услугах и спецпредложениях

Посмотреть все рассылки «1С‑Рарус»

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

Посмотреть все рассылки «1С-Рарус»

Иконка «Предупреждение» Отправляя эту форму, Вы соглашаетесь с Политикой конфидециальности и даете согласие на обработку персональных данных компанией «1С-Рарус»

Заинтересованы в сотрудничестве?
Нужна консультация?
Свяжитесь с нами!