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

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

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

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

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

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

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

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

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

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

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

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

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

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

С полным списком инструментов можно ознакомиться тут 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 является задача (job), задача содержит в себе ряд этапов (stage), которые состоят из шагов (step). Под задачей подразумевается целостный набор действий, приводящий к получению конечного результата.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

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

  

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

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

  

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

  

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

Для примера ниже приведен полный текст команды 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",
				Хранилище,
				ВерсияХранилища
			)
		);
		
	КонецЕсли;

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

КонецПроцедуры

Команды_СборкаРелизов_СозданиеРабочейБазы

06.10.2020 OS1, 3.3 КБ

Скачать

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

  

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

  

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

• Последним шагом размещаем итоговые материалы на внутреннем сервере и 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 запускаться в распределенном режиме:

Перед реализацией, выполнив исследование, обнаружили плагин для работы с 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 «Инструменты проверки качества кода» здесь.