Ошибка jenkins при запуске 1с

Удаленный хост принудительно разорвал существующее подключение

Я

   bvb

07.10.19 — 19:31

   Волшебник

1 — 07.10.19 — 19:32

ну и зоопарк…

   bvb

2 — 07.10.19 — 19:32

Перестали работать все базы и УТ 11 и БП

   la luna llena

3 — 07.10.19 — 19:33

(0) у меня сегодня утром было похожее веселье.

включи сетевое окружение, проверь брандмауэр, слетели настройки

   Волшебник

4 — 07.10.19 — 19:33

нужно открыть порты в брандмауэре

   bvb

5 — 07.10.19 — 19:33

(3) Что конкретно проверить ?

   bvb

6 — 07.10.19 — 19:33

Какие !!!!!

   la luna llena

7 — 07.10.19 — 19:35

(6) порты открой, если не знаешь как просто отключи

   bvb

8 — 07.10.19 — 19:35

(1) Меня терзали смутные сомнения можно ли юзать базу по тонкому клиенту не выполняя публикацию в конфигураторе .

Сисадмин заверил что да всегда так делает и видимо рабоатет

   Фрэнки

9 — 07.10.19 — 19:36

   Фрэнки

10 — 07.10.19 — 19:37

   bvb

11 — 07.10.19 — 19:39

   bvb

12 — 07.10.19 — 19:40

(7) У тебя эта байда после накатки обновления вынь ?

   Фрэнки

13 — 07.10.19 — 19:43

(11) так смотри в обсуждении в (10) — по тому обсуждению получается, что этот вылет связан с использованием драйверов для кассового железа.

   bvb

14 — 07.10.19 — 19:46

(13) (10)  у меня 404 Not Found

Касса да подключена в УТ, но с БП такая же хрень

   bvb

15 — 07.10.19 — 21:00

(7) Брандмауэр н сервере 1с отключили — не помогло

   Vstur

16 — 07.10.19 — 21:38

(15) ну, откатите обновления, если считаете, что дело них, что маловероятно

   bvb

17 — 08.10.19 — 12:47

   H A D G E H O G s

18 — 08.10.19 — 13:18

   bvb

19 — 08.10.19 — 13:37

   bvb

20 — 08.10.19 — 13:38

Имеет ли смысл пытаться делать ТиИ ?

   Волшебник

21 — 08.10.19 — 13:40

Надо всё сносить и разворачивать сервер заново.

   Волшебник

22 — 08.10.19 — 13:40

переустанови 1С-сервер

   bvb

23 — 08.10.19 — 13:46

   bvb

24 — 08.10.19 — 13:50

   H A D G E H O G s

25 — 08.10.19 — 14:31

Готов посмотреть, если будет доступ к серверу 1С, SQL

   H A D G E H O G s

26 — 08.10.19 — 14:31

liveups@yandex.ru

   bvb

27 — 08.10.19 — 15:10

Отписался

(0) была на прошлой неделе такая проблема, правда на тестовом сервере (20 тестовых баз по 500 гб). После каких-то действий стороннего разработчика (он упорно говорит что ничего не делал), начал падать рабочий процесс, в дамп. Перенес базу на отдельный кластер для теста, начала падать процесс нового кластера. Проблема решилась восстановлением базы SQL из SQL бэкапа (Благо тестовый сервак был). Переподключение не помогало, перезапуск сервака непомогал, чистка всех кэшей не помогала, видимо какой-то сбой в связке 1С Сервер — MSSQL.

(1c 8.3.14.1779, MSSQL 2008 r2)

есть сервер 1с он стоит 192.168.0.204 там же стоит sql
есть сервер терминалов 192.168.0.2 на нем клиен 1с и там всё гуд
(тут же стоит ключ сетевой )
но есть ещё 1 сервер терминалов 192.168.11.111 на нем 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");
	ПутьДляЗапуска   = ОбъединитьПути(ПутьКПлатформе, ВерсияПлатформы, "bin1cv8.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 всегда можно увидеть статус выполняемого этапа и шага:

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

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

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

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

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

Для упрощения жизни тестировщикам и разработчикам эти операции мы будем автоматизировать. Рассмотрим сценарий тестирования консистентности ролей в «Альфа-Авто: Автосалон+Автосервис+Автозапчасти Корп, редакция 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 для автоматизации процесса анализа конфигурации.

• Пользователь помещает изменения в хранилище.
• 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 «Инструменты проверки качества кода» здесь.

FAQ

• Проблемы с первичным запуском

  1. Появляется ошибка, в которой есть текст: «Неизвестный идентификатор формы».
  2. При открытии внешних обработок могут появляться окна с предупреждениями безопасности.
  3. При открытии bddRunner или xddTestRunner появляются сообщения Неизвестный идентификатор плагина: <ЗагрузчикКаталога> при попытке загрузить тесты
  4. При интерактивном запуске не загружаются и не выполняются фичи, открывается только форма bddRunner.
  5. При пакетном запуске не загружаются и не выполняются фичи, открывается только форма bddRunner.
  6. Я подключаюсь по RDP к серверу. И фича выполняется нормально. Но если свернуть окно RDP, то возникает ошибка.

• Запуск из командной строки

  1. Как решать проблемы при автоматическом запуске тестовфичсценариев

  2. Как быстро выполнить одну фичу или фичи из одного каталога?

  3. Каким образом увидеть лог выполнения фич, сценариев и шагов или подробный лог при выполнении в командной строке, например, в логе CI-сервера — Jenkins, Gitlab и т.п.

• BDD

  1. Как мне удалить в транзакции созданные данные?
  2. Где мне лучше создавать служебные данные для выполнения сценария?
  3. Если в сценарии возникла ошибка, модальное окно и т.д., как мне гарантированно закрыть все эти окна, чтобы следующий сценарий не падал?
  4. Как проверять поведение системы под разными ролями?
  5. Почему у меня не работает тэг @tree?
  6. Я вызвал метод Ванесса.ЗапретитьВыполнениеШагов(), затем я подключаю свой таймер, и мне надо сделать, чтобы шаг упал.
  7. Как использовать Sikuli-скрипты?
  8. Как для УФ (управляемой формы) и ОФ (обычной формы) шаги сделать общими?
  9. Что нужно сделать, чтобы увидеть собственные шаги в форме Известные шаги?
  10. Не удается выполнить шаги для выбора типа метаданного в форме «Выбор типа данных».
  11. Не удается установить поле отбора.
  12. Как правильно заполнить каталоги библиотечных шагов в json-файле настройки bdd-части Ванесса-АДД?
  13. Как пропустить сценарий, чтобы он не падал?
  14. Можно ли использовать быстрый выбор из списков 1С в полях ссылочных реквизитов?
  15. Как использовать поискпроверку содержимого в таблицахдинамических списках?
  16. Как фильтроватьвключать отбор в таблицахдинамических списках?
  17. Как проверить правильность проведения документа?
  18. Где можно посмотреть список всех тегов?

• Плагины

  1. Как вызвать код плагина на сервере при запуске в управляемой форме?
  2. Как работать с файлами внутри тестов/шагов? Как получить путь к текущему файлу или к файлу рядом с ним?
  3. Описание плагинов

• Клиенты тестирования

  1. Как приложению понять, что оно запущено в режиме тест-клиент через опцию /TESTCLIENT?

• Скриншоты

  1. Как сохранять скриншоты при ошибках сценариев?
  2. На CI сервере скриншот формируется, но вместо изображения чёрный экран. Как настроить сервер CI?
  3. Как при возникновении ошибки на CI получить скриншоты всех окон 1С?

• Отчет Allure

  1. Как получить отчет Allure у себя на компьютере под Windows?
  2. Можно в отчет Аллюр передавать дополнительные данные для отображения в шаге?

• Общие вопросы работы

  1. Как поставить точку останова (брейкпоинт) во внешней обработке для отладки?

• Доработка ADD

  1. Как запустить фичу из поставки Vanessa.ADD у себя в базе?
  2. Как быстро написать проверочную фичу для новой возможности, реализуемой внутри самого Vanessa.ADD или его плагина?

Проблемы с первичным запуском

1. Появляется ошибка, в которой есть текст: «Неизвестный идентификатор формы».

Это означает, что есть два или более epf файла, у которых совпадает поле Имя (которое находится около Синонима и Комментария).

Решение:

Переименовать один epf файл.

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

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

Подробно этот механизм описан здесь.

Решение описано по ссылке

Кратко: Если хотите выключить этот механизм для всех баз, пропишите в файле conf.cfg строку: DisableUnsafeActionProtection=.*

3. При открытии bddRunner или xddTestRunner появляются сообщения Неизвестный идентификатор плагина: <ЗагрузчикКаталога> при попытке загрузить тесты

Возможно, запущено 1С:Предприятие без пользователей. В этом случае 1С не применяет настройки безопасного режима.

Решение:

• нужно создать хотя бы одного пользователя,
• снять у него флаг «Защита от опасных действий» и
• запустить 1С:Предприятие для этого пользователя.

4. При интерактивном запуске не загружаются и не выполняются фичи, открывается только форма bddRunner

Возможные причины:

• У Вас не задан список библиотек на закладке Библиотеки

  Решение:

  • Сначала очистите список библиотек — например, кнопкой Очистить
  • Далее Перезапустите bddRunner
  • Автоматически подставится путь к системным библиотекам Vanessa.ADD — $instrumentsRoot/features/libraries
  • Новые настройки будут сохранены автоматически

• У Вас заданы неверные библиотеки,
  например, используются библиотеки от нашего старого продукта vanessa-behavior

  Решение:

  • Или примените решение выше с полной очисткой библиотек
  • Или добавьте системную библиотеку $instrumentsRoot/features/libraries в список библиотек
  • И далее обязательно нажмите Сохранить настройки

5. При пакетном запуске не загружаются и не выполняются фичи, открывается только форма bddRunner

У Вас неверный/устаревший/ json-файл настроек, несовместимый формат со штатным json, например, что читает 1С 😦

Например:

• одинарный слеш не разрешен — используйте или или /
• или одинарные кавычки ` или ’ не разрешены — используйте "
• Пример правильной настройки

	"КомандаСделатьСкриншот": ""C:Program Files (x86)IrfanViewi_view32.exe" /capture=1 /convert=",

Разбор проблемы в https://xdd.silverbulleters.org/t/pri-paketnom-zapuske-ne-zagruzhayutsya-i-ne-vypolnyayutsya-fichi-otkryvaetsya-tolko-bddrunner/2132

6. Я подключаюсь по RDP к серверу. И фича выполняется нормально. Но если свернуть окно RDP, то возникает ошибка.

Это связано с особенностью платформы 1С. Некоторые методы платформы (кнопконажималки) не работают, когда погашена видеокарта (а RDP клиент её гасит, когда вы его сворачиваете). Поэтому не надо использовать RDP для доступа к CI (или другим) серверам, когда вы хотите использовать кнопконажималку.

Запуск из командной строки

1. Как решать проблемы при автоматическом запуске тестовфичсценариев

Автоматический запуск рекомендуется выполнять с помощью команд инструмента Vanessa-Runner.

• ‘vrunner vanessa’ — для запуска фич и сценариев
• ‘vrunner xunit’ — для запуска тестов, в т.ч. и дымовых тестов

Простой чек-лист проверки правильности

• убедитесь в правильности указания строки подключения
  • правильная строка подключения к ИБ формируется по ключам запуска 1С — или ‘/FfilePath’ или ‘/SserverPath’
    • Например, для файловых баз —ibconnection /FC:base1 или —ibconnection /F./base1 или —ibconnection /Fbase1
    • Или для серверных баз —ibconnection /Sservernamebasename
• в json-файлах нужно указывать двойные обратные слеши "buildsmoke" или для строки подключения "/Sservernamebasename"
• проверьте кодировку json-файла, требуется кодировка UTF-8
• убедитесь, что указана необходимая версия платформы 1С
  • проверьте строковый ключ —v8version вида «8.3», «8.3.15», «8.3.10.2650»
  • убедитесь, что указанная платформа 1С установлена на машине
• включите полный отладочный лог при выполнение пакетов OneScript
  • выполните ‘SET LOGOS_LEVEL=DEBUG’ перед выполнением нужной команды
  • посмотрите лог команды и определите правильность указания платформы 1С, строки соединения с ИБ и другие параметров
  • выключение полного лога выполняется через ‘SET LOGOS_LEVEL=’

2. Как быстро выполнить одну фичу или фичи из одного каталога?

Правильнее запускать фичи из командной строки с помощью инструмента Vanessa-Runner.

Для прогона одной фичи используйте команду

vrunner vanessa --settings toolsvrunner.json --path ПутьКФиче

или

vrunner vanessa --settings toolsvrunner.json --path ПутьККаталогуФич

где

• toolsvrunner.json — путь к файлу настройки запуска, документированный в

  • Настройка запуска тестов или проверки поведения через Vanessa-ADD и Vanessa-Runner
  • Пример запуска проверки поведения через Vanessa-ADD и Vanessa-Runner

• ПутьКФиче или ПутьККаталогуФич — прямые или относительные пути к конкретной фиче или каталогу с фичами

3. Каким образом увидеть лог выполнения фич, сценариев и шагов или подробный лог при выполнении в командной строке, например, в логе CI-сервера — Jenkins, Gitlab и т.п.

• Для этого нужно настроить файл настройки в json-формате и указать его использование при запуске в командной строке с помощью vanessa-runner или в командной строке запуска 1С

• В файле настройки нужно включить 2 параметра

  • включить "ДелатьЛогВыполненияСценариевВТекстовыйФайл": true
  • установить путь к логу выполнения. Например, "ИмяФайлаЛогВыполненияСценариев": "$workspaceRoot/build/log.txt"

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

• Также можно включить более подробный лог с показом выполнения каждого шага, а не только сценариев

  • в файле настройки нужно включить параметр "ВыводитьВЛогВыполнениеШагов": true

• Также можно включить намного более подробный лог с показом всех отладочных сообщений

  • в файле настройки нужно включить параметр "DebugLog": true

BDD

1. Как мне удалить в транзакции созданные данные?

• В BDD не обязательно их удалять за собой.
• Если всё же хотите, Вы можете гарантированно удалить их в процедуре ПередОкончаниемСценария(). Она срабатывает в любом случае, даже если сценарий упал.
• Если создавались данные из макета (Данные = Ванесса.СоздатьДанныеПоТабличномуДокументу(Макет)), то можно использовать метод Ванесса.УдалитьСозданныеДанные(Данные).
• Лучше стремиться к тому, чтобы сценарий сам обеспечивал себе окружение, чтобы успешно выполниться.

2. Где мне лучше создавать служебные данные для выполнения сценария?

• В секции Контекст feature файла
• В процедуре ПередНачаломСценария()

3. Если в сценарии возникла ошибка, модальное окно и т.д., как мне гарантированно закрыть все эти окна, чтобы следующий сценарий не падал?

В секции контекст надо добавить шаг И Я закрыл все окна клиентского приложения.

А ещё лучше создать экспортный сценарий и в него добавить этот шаг. А в секции Контекст вызывать экспортный сценарий.

4. Как проверять поведение системы под разными ролями?

Надо запустить несколько TestClient на разных портах и переключаться между ними.

5. Почему у меня не работает тэг @tree?

Для работы тега @tree надо использовать либо только табы, либо только пробелы. В пределах одной фичи нельзя в отступах строк использовать и пробелы, и табы.

6. Я вызвал метод Ванесса.ЗапретитьВыполнениеШагов(), затем я подключаю свой таймер, и мне надо сделать, чтобы шаг упал.

В этом случае вместо вызова исключения надо сделать Ванесса.ПродолжитьВыполнениеШагов(Истина)

7. Как использовать Sikuli-скрипты?

• Установите SikuliX согласно инструкции http://sikulix.com/quickstart/
• Ознакомьтесь с http://sikulix-2014.readthedocs.io/en/latest/faq/010-command-line.html
• Укажите через path путь к каталогу с runsikulix(.cmd)
• Разрабатывайте свои Sikuli-скрипты с помощью SikuiliX IDE (http://sikulix-2014.readthedocs.io/en/latest/index.html) либо используйте имеющиеся
• Выполнение скрипта в реализации шага вызывайте через Ванесса.ВыполнитьSikuliСкрипт()

8. Как для УФ (управляемой формы) и ОФ (обычной формы) шаги сделать общими?

• Разместить код шага в модуле объекта обработки,
• В коде управляемой формы в клиентском методе шага нужно вызвать серверный метод, в котором
  • выполнить ОбъектНаСервере = ЗначениеФормыВОбъект("Объект") и
  • вызвать код из модуля обработки ОбъектНаСервере.НужныйМетод(...)
• Сигнатуры методов в УФ и ОФ должны совпадать соответственно

9. Что нужно сделать, чтобы увидеть собственные шаги в форме Известные шаги?

• В строке описания шага нужно заполнить последние параметры (4 и 5 параметры) в процедуре ДобавитьШагВМассивТестов. Там как раз задается развернутое описание шага и место в дереве.
• Место в группе можно задавать с учетом иерархии.
  • Указание группы как UI.Формы.Кнопки.Мой шаг расположит шаг в иерархии дерева UI — Формы — Кнопки
• Например,

Ванесса.ДобавитьШагВМассивТестов(ВсеТесты, "Пауза(Парам01)","Пауза", "И     Пауза 1",
	"Позволяет сделать паузу нужной длительности.", "Прочее.Сделать паузу");

10. Не удается выполнить шаги для выбора типа метаданного в форме «Выбор типа данных».

• В последних версиях Vanessa.ADD реализована автоматическая генерация правильных шагов выбора метаданного на основе записи действий пользователя с необходимыми подсказками.

• Важно использовать правильную последовательность шагов, например, вместо созданных на старых версиях Vanessa.ADD

   # И я нажимаю кнопку выбора у поля "Реквизит1"
   Тогда открылось окно 'Выбор типа данных'
   И В форме "Выбор типа данных" в таблице "" я перехожу к строке:
   	| ''       |
   	| 'Нужное метаданное' |
   И В форме "Выбор типа данных" в ТЧ "" я выбираю текущую строку

11. Не удается установить поле отбора.

Проблема:

Если пытаться установить поле отбора (колонка «поле») у динамического списка, используя шаг «И в таблице «Source» я разворачиваю строку:», то 1С почему-то не хочет выполнять этот шаг (не разворачивает ветку).

Например: мне нужен отбор по Юр. или Физ.Лиц у контрагента.

Решение:

Можно просто установить текст в поле отбора:

И в таблице "КомпоновщикНастроекПользовательскиеНастройкиЭлемент0Отбор" из выпадающего списка с именем "КомпоновщикНастроекПользовательскиеНастройкиЭлемент0ОтборЛевоеЗначение" я выбираю по строке 'Контрагент.Юр/Физлицо'

12. Как правильно заполнить каталоги библиотечных шагов в json-файле настройки bdd-части Ванесса-АДД?

Важно правильно указать каталог библиотек Ванесса-АДД.

Если у вас Linux, регистр имен каталогов также важен — используйте имена в нижнем регистре.

В json-файл нужно добавить следующие строки

"КаталогиБиблиотек": [
			"$instrumentsRoot/./features/libraries"
	]

также можно использовать устаревший вариант ./features/libraries

Если есть собственные каталоги библиотечных шагов, их нужно добавить после библиотек Ванесса-АДД.

Например, следующим образом

"КаталогиБиблиотек": [
		"$instrumentsRoot/./features/libraries",
		"$workspaceRoot/feature-libs"
	]

13. Как пропустить сценарий, чтобы он не падал?

• Можно его закомментировать в тексте фичи (символ #).
• Можно поставить сценарию тег — и использовать фильтры по тегу.
• Да пусть падает. Тем более если он не реализован, то он будет желтым, а если реализован — тогда почему он падает?

14. Можно ли использовать быстрый выбор из списков 1С в полях ссылочных реквизитов?

Опасно использовать следующие варианты шагов

• И из выпадающего списка "Принял" я выбираю точное значение 'Иванов Иван Иванович'
• И из выпадающего списка с именем "ПлательщикМестоОплаты" я выбираю точное значение 'Москва'

Проблема в том, что подобный «быстрый выбор» актуален только для текущей базы и вашего пользователя.

При запуске на другой базе в списке «быстрого выбора» наверняка не будет этих значений, а будет пусто или будут какие-то другие значения (

Вместо этих шагов нужно

• использовать кнопку «Показать все» (или кнопка с тремя точками)
• далее искать в форме выбора
• и затем выбирать найденный элемент в форме выбора

15. Как использовать поискпроверку содержимого в таблицахдинамических списках?

При работе с тест-клиенто нужно помнить про особенности его работы с тест-клиентом.
Анализ таблиц на нем часто может выполняться только полным перебором (от первой до последней строки).
Фактически, если активна большая таблица (динамический список), то переход к нужной строке или проверка содержимого могут долго выполняться.

Для ускорения анализа динамических таблиц и больших таблиц правильнее включить отбор любым из способом (средствами настройки списка через СКД или поиск) и только потом проверять содержимое или выполнять переход к нужной строке. см.ниже п.16

Есть несколько вариантов проверки содержимого таблиц на тест-клиенте.

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

15.1. Шаги поиска только нужных строк — подходят для большинства сценариев

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

Возможно использовать шаблонный символ *(звездочка) для пропуска каких-то значений.

• шаг И таблица "ИмяТаблицы" содержит строки:
• шаг И таблица "ИмяТаблицы" не содержит строки:

Пример:

И таблица "ИмяТаблицы" содержит строки:
    | ИмяКолонки1 					| ИмяКолонки2 |
    | Значение1 					| Значение2 |
    | Значение * из другой строки 	| Значение * из строк* |

15.2. Шаги равенства по шаблону

• шаг И таблица "ИмяТаблицы" стала равной по шаблону:

Возможно использовать шаблонный символ *(звездочка) для пропуска каких-то значений.

И таблица "ИмяТаблицы" стала равной по шаблону:
    | ИмяКолонки1 					| ИмяКолонки2 |
    | Значение1 					| Значение2 |
    | Значение * из другой строки 	| Значение * из строк* |

15.3. Шаги точного равенства

Эти шаги проверяют только таблицу полностью. В таблице должны быть только указанные строки.
Никаких других строк в таблице быть не должно!

Использование этих шагов требуется крайне редко. Рекомендуется использовать либо шаги из 15.1 либо из 15.2

• шаг И таблица "ИмяТаблицы" стала равной:
• шаг И я жду, что таблица "ИмяТаблицы" станет равна данной в течение 20 секунд:

И таблица "ИмяТаблицы" стала равной:
    | ИмяКолонки1 					| ИмяКолонки2 |
    | Значение1 					| Значение2 |
    | Значение1 из другой строки 	| Значение2 из другой строки |

И я жду, что таблица "ИмяТаблицы" станет равна данной в течение 20 секунд:
    | ИмяКолонки1	| ИмяКолонки2	|
    | Значение1 	| Значение2 	|

16. Как фильтроватьвключать отбор в таблицахдинамических списках?

Для ускорения анализа динамических таблиц и больших таблиц правильнее включить отбор любым из способом (средствами настройки списка через СКД или поиск) и только потом проверять содержимое или выполнять переход к нужной строке.

Для фильтрации списков существует шаги

• И Я устанавливаю фильтр на список:
• И Я устанавливаю фильтр на список если это возможно:

Эти шаги позволяют установить фильтр на список через меню «Ещё/Настроить список».

Шаг И Я устанавливаю фильтр на список если это возможно не выдает исключения, если поля отбора не существует.

Пример:

И Я устанавливаю фильтр на список:
        | Наименование | Содержит | Товар1 |

17. Как проверить правильность проведения документа?

Всегда проверять результаты проведения документа одним из 2х способов (желательно даже совместить их)

• наличие нового документа в форме списке. см. п. 17.1 ниже.
• проверкой отчетов, в которых видны результаты движений документа
  • или отчет «движения документа»
  • или бизнес-отчеты
  • использовать шаги сравнения табличных документов с макетами по шаблону
• но из образцовмакетов отчетов нужно удалять уникальную слабо повторимую инфу — текущие даты, время, имена пользователей, номеракоды, заменяя их на * (шаблон)

Полезные шаги

• Дано Табличный документ "РеквизитТабличныйДокумент" равен макету "ПутьМакета" по шаблону
• И область "R1C1:R10C10" табличного документа "РеквизитТабличныйДокумент" равна макету "ПутьМакета" по шаблону

17.1 Пример проведения документа и проверка наличия документа в форме списка

И я фиксирую номер документа после записи
	И я нажимаю на кнопку 'Записать'
	И я жду, что поле "Номер" перестанет быть пустым в течение 10 секунд
	И     я запоминаю значение поля с именем "Номер" как "НомерДокумента"
И я провожу документ
	И я нажимаю на кнопку 'Провести и закрыть'
	И я жду закрытия окна 'Реализация * от *' в течение 20 секунд
Тогда вижу новый документ с результатами тестирования
	И Я устанавливаю фильтр на список:
		| Организация	| Равно | Первая 				|
		| Контрагент	| Равно | Основной покупатель	|
	Тогда таблица "Список" содержит строки:
		| Номер       		| Организация	| Контрагент 			|
		| $НомерДокумента$	| Первая  		| Основной покупатель	|

18. Где можно посмотреть список всех тегов?

Общего списка всех тегов не ведется.
Основные служебные теги:

• @tree — в фича файле используется иерархия шагов.
• @ExportScenarios — это файл экспортных сценариев.
• Есть еще специальные теги для записи видеоинструкций и инструкций в формате -markdown, -html.
• Также можно задаватьиспользовать собственные теги.

Плагины

1. Как вызвать код плагина на сервере при запуске в управляемой форме?

Практически любой плагин можно подключать на сервере.
Например:

ЗапросыИзБД = ВнешниеОбработки.Создать("ЗапросыИзБД");
ЗапросыИзБД.ПолучитьКоличествоЭлементовСправочникаПоОтбору(...);

Ожидаем = ВнешниеОбработки.Создать("УтвержденияBDD");
Ожидаем.Что(Значение, "Должно быть равно 5, а это не так!").
	Равно(5);

• Небольшое ограничение: нужно помнить, что на сервере нет состояний, поэтому плагины запускаются без состояния.

2. Как работать с файлами внутри тестов/шагов? Как получить путь к текущему файлу или к файлу рядом с ним?

Возможные варианты:

• Используйте организацию файлов через рабочий каталог проекта (рекомендуемый путь)

  • В BDD – Ванесса.Объект.КаталогПроекта
  • В TDD — КонтекстЯдра.Объект.КаталогПроекта
  • Эта настройка задается
    • либо через командную строку (например, через vanessa-runner)
    • либо интерактивно, через форму настроек (Сервис)

• В TDD можно использовать Получить полный путь к текущему файлу теста

  • В тесте нужно определить свойство «ПутьКФайлуПолный»
    • это или Глобальная публичная переменная модуля,
    • или реквизит обработки (для серверных модулей)
  • В этой переменной будет клиентский путь к файлу теста
  • Переменная доступна как на этапе заполнения набора/списка тестов, так и при выполнении

• В BDD также можно использовать шаг И я буду выбирать внешний файл "ИмяФайла" для подмены интерактивных действий пользователя по выбору файла/каталога в окне выбора файлов/каталогов

3. Описание плагинов

• Проверка орфографиии. Плагин использует сервис YaSpeller и позволяет проверять наличие орфографических ошибок в тексте.

  • Подключение и использование плагина:

ПроверкаОрфографии = КонтекстЯдра.Плагин("ПроверкаОрфографии");
Результат = ПроверкаОрфографии.ВыполнитьПроверкуТекста(ТекстНаПроверку); // локальная проверка. Результат - массив с ошибками
ПроверкаОрфографии.ОжидаемЧтоНетОшибок(ТекстНаПроверку); // выбрасывает исключение если были ошибки с подробным описанием

• Настройки:

  • Пропускать слова с цифрами:

ПроверкаОрфографии.ПропускатьСловаСЦифрами(Истина);

- Пропускать url и интернет адреса

ПроверкаОрфографии.ПропускатьУРЛ(Истина);

- Словарь слов исключений

ПроверкаОрфографии.ИспользоватьШаблонДляСловаря(Истина); // проверка вхождения в словарь по рег. выражению
ПроверкаОрфографии.ИспользоватьСловарьИсключений(Словарь); // список слов или текстовый документ с словами-исключениями
                                                      // каждое слово с новой строки

Клиенты тестирования

1. Как приложению понять, что оно запущено в режиме тест-клиент через опцию /TESTCLIENT?

Платформа 1С не предоставляет такой возможности.

Вообще приложение лучше бы не понимать, что он работает в тестовом окружении.

Надежнее юзать режим установки нужных настроек передпри запуске приложения.
Например, json-файлы настройки или другой формат устанавливают нужные тест-настройки.
В БСП используется механизм расширений, которые переустанавливают адреса сервисов на тестовые.

Также в Ванесса-АДД можно при запуске клиента тестирования указать спец. параметр через /C.
например, передавать путь к json-файлу настройки или еще что-то

А затем приложение прочитает этот параметрфайл

• и выставит нужные настройки.
• или определит, что работает в режиме тестирования, если без этого все-таки никак )

Скриншоты

1. Как сохранять скриншоты при ошибках сценариев?

Интерактивная настройка:
	+ Закладка `Сервис`
	+ далее `Автоинструкции`
	+ поле `Консольная команда создания скриншотов`
	  + после строки команды вставляется имя файла и в таком виде команда запускается!

Можно устанавливать
+ как `NirCMD`
+ http://www.nirsoft.net/utils/nircmd.zip
	+ команда `nircmd savescreenshot `

+ так и `IrfanView`
	+ команда `"C:Program Files (x86)IrfanViewi_view32.exe" /capture=1 /convert=`
	+ команда

		""C:Program Files (x86)IrfanViewi_view32.exe" /capture=1 /convert=",

+ Важно только устанавливать 32-разрядные версии !!

Примеры json-файла настройки фиксации скриншотов
	для `NirCMD`:

	"ДелатьСкриншотПриВозникновенииОшибки": true,
	"СниматьСкриншотКаждогоОкна1С": true,
	"КаталогOutputСкриншоты": "$workspaceRoot/build/out/ScreenShots",
	"КомандаСделатьСкриншот": "nircmd savescreenshot "

	"ДелатьСкриншотПриВозникновенииОшибки": true,
	"СниматьСкриншотКаждогоОкна1С": true,
	"КаталогOutputСкриншоты": "$workspaceRoot/build/out/ScreenShots",
	"КомандаСделатьСкриншот": ""C:Program Files (x86)IrfanViewi_view32.exe" /capture=1 /convert=",

2. На CI сервере скриншот формируется, но вместо изображения чёрный экран. Как настроить сервер CI?

Возможные причины и решения:

• Нельзя запускать джоб Jenkins в режиме сервиса. На CI надо настроить автовход под какой-либо учётной записью и в автозагрузку поместить команду запуска джоба Jenkins.
• Нельзя использовать для доступа к CI RDP. Вообще. Надо использовать другой софт для удаленного доступа к нему, например TightVNC. RDP полностью гасит видеокарту (виртуальную или настоящую) при отключении.
• Надо посмотреть схему энергосбережения в Панели управления, там может стоять отключение дисплея через пару минут. Это надо выключить.

3. Как при возникновении ошибки на CI получить скриншоты всех окон 1С?

Пока эта фича работает только под Windows.

• В json-файле, в котором указываются параметры запуска Vanessa-ADD, указать строку: "СниматьСкриншотКаждогоОкна1С": "Истина".
• Установить на CI сервер java 8 (если у вас Jenkins, то скорее всего она у вас уже есть).
• Установить SikuliX версии 1.1 или выше. Брать отсюда. Там надо скачать sikulixsetup-1.1.1.jar.
• Прописать в переменной PATH файл runsikulix.cmd.

Отчет Allure

1. Как получить отчет Allure у себя на компьютере под Windows?

• Скачать дистрибутив Allure отсюда и установить.
• Прописать в переменную Path путь к каталогу, где лежит allure.bat

Далее для получения отчета используйте один из трех вариантов:

• Для использования через командную строку:
  • Вызвать команду call allure generate {каталог, где лежат ваши xml в формате Allure}
  • Вызвать команду call allure open
• или установить флаг «Показать отчет Allure в браузере» на закладке Сервис > Отчет о запуске сценариев и сохранить настройки.
  • В этом случае после выполнения тестов и формирования отчетов Allure BDDRunner самостоятельно выполнит обе команды и покажет отчет Allure в браузере
• или выполнить команду Внешние инструменты > Отобразить отчет Allure в браузере.

2. Можно в отчет Аллюр передавать дополнительные данные для отображения в шаге?

Можно.

Решение:

Использовать шаг:

И Я подключаю файл '$instrumentsRoot/features/libraries/manually/setlabelsallure.feature' к шагу

ПлагинАллюра = Ванесса.Плагин("Аллюр2Отчет");
ПлагинАллюра.ДобавитьФайлКТекущемуШагу(ПутьКФайлу);
ПлагинАллюра.ДобавитьJSONКТекущемуШагу(ТекстДляДобавления, ИмяФайла);
ДобавитьXMLКТекущемуШагу(ТекстXML, Наименование);

Если необходимо прикрепить данные, тогда:

ПлагинАллюра.ДобавитьДвоичныеДанныеКТекущемуШагу(...)
ПлагинАллюра.ДобавитьТекстКТекущемуШагу(ТекстДляДобавления, ИмяФайла)

Общие вопросы работы

1. Как поставить точку останова (брейкпоинт) во внешней обработке для отладки?

• Используйте штатный механизм отладки 1С, если у вас
  • файловая база
  • или клиент 1С и сервер 1С находятся на одной машине.
• Если это не так, тогда более сложный путь:
  • Закрыть сеанс TestManager.
  • Открыть сеанс TestManager.
  • Открыть через меню Файл > Открыть файл обработку, в которой стоит точка останова.
  • Только после этого открыть bddRunner.epf.
  • Теперь остановка на точке остановки во внешней обработке будет работать. Но до первого изменения кода в ней. Если изменили код, то надо повторить все действия с начала.

Доработка ADD

1. Как запустить фичу из поставки Vanessa.ADD у себя в базе?

Большинство фич, которые идут в поставке Vanessa.ADD, требуют, чтобы их запускали в специальной служебной базе. Т.е. надо собрать служебную базу и подготовить другие файлы.

Самый простой способ

• выполнить команду opm run init согласно Руководству контрибьютора
• и немного подождать

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

Для этого нужно выполнить самотестирование Ванесса-АДД.
Самый простой способ — использовать режим тест-клиент и специальные шаги для самотестирования.

Чек-лист:

• создаются 2 фичи
  • служебная фича
    • назначение фичи — выполнить шаги с новыми возможностями внутри Ванесса-АДД, подключенной внутри тест-клиента
    • в служебном каталоге features/Support/Templates
    • обязательно установить тег @IgnoreOnCIMainBuild для исключения выполнения этой фичи
  • основная проверочная фича
    • назначение фичи — протестировать результаты служебной фичи в Ванесса-АДД, подключенной внутри тест-клиента
      • например, проверить состояние формы, полей, посмотреть служебные сообщения c обычных шагов тест-клиента и других шагов Ванесса-АДД
    • ее можно создать в этом же служебном каталоге
      • или в любом другом подкаталоге features/libraries
    • В этой фиче рекомендуется использовать специальный шаг `Когда Я выполняю служебную фичу «ИнформаторСлужебнаяФича» в VanessaADD в режиме TestClient’
    • а далее обращаться к шагам работы с тест-клиентом

Примеры таких фич:

• основная фича Информатор.feature
  • служебная фича ИнформаторСлужебнаяФича.feature
• основная фича РедактированиеТаблицыGherkin.feature
  • служебная фича ФичаДляПроверкиРедактораТаблицыGherkin.feature

TDD

Дымовые тесты

Возникающая ошибка «1С: Нет ответа от сервера server_addr= d:/jenkins/ci_builder …»

появляется при первом запуске 1С, при втором и последующих может не проявлятся.

Можем появлятся при наличии лишней записи у сервера с ключем 1С
а также проблемах ДНС, проявляется при наличии домена и не верных настройках ДНС

исправление,
1. перевести имя сервера в сервере предприятия 1С на IP адресс вместо имени сервера.
2. проверить разрешение имен сервера в сервере днс.
3. проверить физические проблемы соединения по сети и доступ к домену.

0
Sys Name_0: LUBGRSRV
Sys Type_0: System Product Name, x64-based PC
Phis Mem_0: 4109426688
BIOS_0: American Megatrends Inc., 20101029000000.000000+000, 0402 , 2, 6
CPU_0: CPU0, Intel64 Family 6 Model 37 Stepping 5, 64, 64, 512, 3200, BFEBFBFF00020655, 9477, LGA1156
NET_0: [00000000] WAN Miniport (SSTP), ROOTMS_SSTPMINIPORT000
NET_1: [00000001] WAN Miniport (IKEv2), ROOTMS_AGILEVPNMINIPORT000
NET_2: [00000002] WAN Miniport (L2TP), ROOTMS_L2TPMINIPORT000
NET_3: [00000003] WAN Miniport (PPTP), ROOTMS_PPTPMINIPORT000
NET_4: [00000004] WAN Miniport (PPPOE), ROOTMS_PPPOEMINIPORT000
NET_5: [00000005] WAN Miniport (IPv6), ROOTMS_NDISWANIPV6000
NET_6: [00000006] WAN Miniport (Network Monitor), ROOTMS_NDISWANBH000
NET_7: [00000007] Сетевая карта Realtek RTL8168D/8111D Family PCI-E Gigabit Ethernet NIC (NDIS 6.20), BC:AE:C5:BE:C8:BE, PCIVEN_10EC&DEV_8168&SUBSYS_83A31043&REV_034&FD5DF6&0&00E5
NET_8: [00000008] Адаптер D-Link DFE-520TX PCI Fast Ethernet, 00:1B:11:B2:FF:21, PCIVEN_1106&DEV_3106&SUBSYS_14051186&REV_8B4&3A440333&0&08F0
NET_9: [00000009] WAN Miniport (IP), ROOTMS_NDISWANIP000
NET_10: [00000010] Kerio Virtual Network Adapter, 44:45:53:54:4F:53, ROOTKVNETID000
NET_11: [00000011] RAS Async Adapter, 20:41:53:59:4E:FF, SW{EEAB7790-C514-11D1-B42B-00805FC1270E}ASYNCMAC
DISK_0: KINGSTON SV300S37A120G ATA Device, IDEDISKKINGSTON_SV300S37A120G__________________541ABBF05&2D5A9710&0&0.1.0, 512, 63, 14593, 255, 3721215, 234436545, 120031511040
DISK_1: ST3500413AS ATA Device, IDEDISKST3500413AS_____________________________JC45____5&2D5A9710&0&0.0.0, 512, 63, 60801, 255, 15504255, 976768065, 500105249280
PART_0: Disk #1, Partition #0, 32256, 234436482, 120031478784
PART_1: Disk #0, Partition #0, 32256, 102398247, 52427902464
PART_2: Disk #0, Partition #1, 52427934720, 874353690, 447669089280
VIDEO_0: Стандартный VGA графический адаптер, PCIVEN_8086&DEV_0042&SUBSYS_83831043&REV_183&11583659&0&10
VIDEO_1: Radmin Mirror Driver V3, ROOTDISPLAY000′
36:01.426004-0,EXCP,2,process=1cv8c,OSThread=4660,Exception=0874860b-2b41-45e1-bc2b-6e186eb37771,Descr=’srcbackbassrclicensebaseimpl.cpp(6711):
0874860b-2b41-45e1-bc2b-6e186eb37771: Ошибка программного лицензирования. Превышено максимальное количество пользователей, разрешенное файлом программной лицензии:

file://C:/ProgramData/1C/licenses/20191112145717.lic

File=d:jenkinsci_builder2windowsbuild2platformsrcbackbassrclicensebaseimpl.cpp(5435)’
36:01.426006-0,EXCP,1,process=1cv8c,OSThread=4660,Exception=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3,Descr=»srcmngclnsrcinfobaseregistry.cpp(1360):
9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Ошибка при выполнении файловой операции ‘C:ProgramData1C1CEStartibases.v8i’. Неожиданный вызов метода ‘FileObject::setEOF’: d:jenkinsci_builder2windowsbuild2platformsrccoresrcfiles.cpp(643): Неожиданный вызов метода ‘FileObject::setEOF'»
36:01.598000-0,CONN,2,process=1cv8c,OSThread=4660,Txt=’addrBelongsToThisComputer2, address=s01, result=false’
36:01.598001-0,CONN,2,process=1cv8c,OSThread=4660,ClientID=1,Protected=1,Txt=’Connected, client=(2)192.168.11.111:13270, server=(2)192.168.0.204:1541′
36:01.598002-0,CONN,2,process=1cv8c,OSThread=4660,Txt=’Ping direction opened: address=192.168.0.204:1541,pingTimeout=15000,pingPeriod=3000,lastSentTs=155357886,lastReceivedTs=155357886,lastReceivedTestTs=,directionID=df684d5d-4d23-4e4a-82d5-ff34ae505e92′
36:01.598003-0,CONN,2,process=1cv8c,OSThread=4660,Txt=’Connection added to ping direction: address=192.168.0.204:1541,pingTimeout=15000,pingPeriod=3000,lastSentTs=155357886,lastReceivedTs=155357886,lastReceivedTestTs=,clientID=1′
36:01.598004-0,CONN,2,process=1cv8c,OSThread=4660,Txt=Clnt: MyUserName1: Администратор@LUBGRSRV
36:01.879001-0,CONN,2,process=1cv8c,OSThread=4660,Txt=Clnt: DstUserName1: S01USR1CV8 StartProtocol: 0 Success
36:01.910001-0,CONN,2,process=1cv8c,OSThread=4660,Txt=Clnt: MyUserName2: LUBGRSRVАдминистратор
36:02.050001-0,CONN,2,process=1cv8c,OSThread=4660,Txt=’Connection removed from ping direction: address=192.168.0.204:1541,pingTimeout=15000,pingPeriod=3000,lastSentTs=155357886,lastReceivedTs=155357886,lastReceivedTestTs=,clientID=1′
36:02.050002-0,CONN,2,process=1cv8c,OSThread=4660,Txt=’Ping direction closed: address=192.168.0.204:1541,pingTimeout=15000,pingPeriod=3000,lastSentTs=155357886,lastReceivedTs=155357886,lastReceivedTestTs=’
36:02.050003-0,CONN,2,process=1cv8c,OSThread=4660,Txt=’Ping direction statistics: address=192.168.0.204:1541,pingTimeout=15000,pingPeriod=3000,period=452,packetsSent=0,avgResponseTime=0,maxResponseTime=0,packetsTimedOut=0,packetsLost=0,packetsLostAndFound=0′
36:02.050004-515003,CONN,1,process=1cv8c,OSThread=4660,ClientID=1,Txt=Outgoing connection closed
36:02.113000-0,CONN,2,process=1cv8c,OSThread=4660,ClientID=2,Protected=1,Txt=’Connected, client=(2)192.168.11.111:13273, server=(2)192.168.0.204:1567′
36:02.113001-0,CONN,2,process=1cv8c,OSThread=4660,Txt=’Ping direction opened: address=192.168.0.204:1567,pingTimeout=15000,pingPeriod=3000,lastSentTs=155358401,lastReceivedTs=155358401,lastReceivedTestTs=,directionID=df684d5d-4d23-4e4a-82d5-ff34ae505e92′
36:02.113002-0,CONN,2,process=1cv8c,OSThread=4660,Txt=’Connection added to ping direction: address=192.168.0.204:1567,pingTimeout=15000,pingPeriod=3000,lastSentTs=155358401,lastReceivedTs=155358401,lastReceivedTestTs=,clientID=2′
36:02.113003-0,CONN,2,process=1cv8c,OSThread=4660,Txt=Clnt: MyUserName1: Администратор@LUBGRSRV
36:02.331001-0,CONN,2,process=1cv8c,OSThread=4660,Txt=Clnt: DstUserName1: S01USR1CV8 StartProtocol: 0 Success
36:02.362001-0,CONN,2,process=1cv8c,OSThread=4660,Txt=Clnt: MyUserName2: LUBGRSRVАдминистратор
36:02.783001-0,CONN,2,process=1cv8c,OSThread=4660,Txt=Clnt: MyUserName1: Администратор@LUBGRSRV
36:02.815001-0,CONN,2,process=1cv8c,OSThread=4660,Txt=Clnt: DstUserName1: S01USR1CV8 StartProtocol: 0 Success
36:02.846001-0,CONN,2,process=1cv8c,OSThread=4660,Txt=Clnt: MyUserName2: LUBGRSRVАдминистратор
36:03.205002-0,EXCP,2,process=1cv8c,OSThread=4660,Exception=580392e6-ba49-4280-ac67-fcd6f2180121,Descr=’srcvrscoresrcvresourcesessionimpl.cpp(529):
580392e6-ba49-4280-ac67-fcd6f2180121: Неправильное имя пользователя или пароль
Ошибка при выполнении запроса POST к ресурсу /e1cib/login:’
36:12.237000-0,CONN,0,process=1cv8c,OSThread=4160,Txt=’Ping direction statistics: address=192.168.0.204:1567,pingTimeout=15000,pingPeriod=3000,period=10124,packetsSent=3,avgResponseTime=16,maxResponseTime=16,packetsTimedOut=0,packetsLost=0,packetsLostAndFound=0′
36:14.249001-0,SCOM,3,process=1cv8c,OSThread=4660,Func=’setSrcProcessName(RHostRoot,RHostRoot)’

Автоматизация тестирования конфигураций «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");
	ПутьДляЗапуска   = ОбъединитьПути(ПутьКПлатформе, ВерсияПлатформы, "bin1cv8.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 всегда можно увидеть статус выполняемого этапа и шага:

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

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

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

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

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

Для упрощения жизни тестировщикам и разработчикам эти операции мы будем автоматизировать. Рассмотрим сценарий тестирования консистентности ролей в «Альфа-Авто: Автосалон+Автосервис+Автозапчасти Корп, редакция 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 для автоматизации процесса анализа конфигурации.

• Пользователь помещает изменения в хранилище.
• 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 «Инструменты проверки качества кода» здесь.