дымовые тесты 1с что это
Дымовые тесты для забывчивых/торопливых
В итоге, решил поразбираться и написать какой-то набор дымовых тестов, что-то проверяющих на основании метаданных конфигурации. Для этого выработал себе задачи-минимум, исходя из которых будут писаться инструменты:
Поехали
Ок. Поехали далее
По нашим исходным задачам, понимаем, что в каждом будущем тесте мы будем просматривать какие-то списки метаданных. Можно, конечно, написать какой-то типовой код формирования таких списков. И потом с модификациями копипастить этот код из теста в тест. Но мы ведь любим красоту и лаконичность:) Поэтому заморачиваемся далее. И пишем свой плагин, который будет перечислять наши требуемые метаданные и вызывать какую-то нами определяемую процедуру.
И вот плагин написан (кто не в курсе, это обычная внешняя обработка, только с определенными типовыми методами). Называется ИтераторМетаданных. Его интерфейс описан далее.
Для построения дерева можно и не заполнять реквизит ДопустимыеМетаданные. В этом случае дерево будет заполнено максимальным количеством метаданных. Для этого используется приватная функция плагина ВсеКоллекцииМетаданных().
Пишем тесты
Вариант 1. Тест на чтение Не-Администраторами
Этот вариант задумывался как раз изначально. И, может быть, чуть сложнее, чем будет следующий вариант. В этом тесте будем использовать метод Итератор.Перечислить(. ).
В стандартном методе обработки тестирования проинициализируем Итератор:
Посмотрим еще раз на интерфейсы callback-процедур для метода Итератор.Перечислить(. ) и напишем один интерфейсный метод. Он будет отвечать и за обработку разделов, и за обработку объектов метаданных:
И самый конечный метод, который будет тестировать объект метаданных:
В этом методе используется переменная модуля ПривилегированныеРоли. Это Соответствие, которое заполняем ролями (Объект метаданных: Роль), обладающими расширенными полномочиями на чтение. Инициализируем и заполняем переменную также в стандартном методе Инициализация. Здесь этот код показывать особого смысла нет. См. в исходниках.
Вариант 2. Тест на проверку значений свойств РежимУправленияБлокировкойДанных
Как уже писал, это больше «академический» тест. В реальных разработках он будет иметь ценность лишь для конфигураций, которые находятся в стадии перевода с одного режима управления блокировками на другой.
Код уже не так интересен, и будет расположен в спойлерах.
Опять в стандартном методе обработки тестирования проинициализируем Итератор. Но уже немного по-другому.
А теперь для построения дерева тестов, воспользуемся функцией Итератор.ДеревоМетаданных().
Ваш браузер устарел, пожалуйста обновите ваш браузер пройдя по ссылке www.microsoft.com/download
Дымовые тесты для забывчивых/торопливых
В итоге, решил поразбираться и написать какой-то набор дымовых тестов, что-то проверяющих на основании метаданных конфигурации. Для этого выработал себе задачи-минимум, исходя из которых будут писаться инструменты:
Поехали
Ок. Поехали далее
По нашим исходным задачам, понимаем, что в каждом будущем тесте мы будем просматривать какие-то списки метаданных. Можно, конечно, написать какой-то типовой код формирования таких списков. И потом с модификациями копипастить этот код из теста в тест. Но мы ведь любим красоту и лаконичность:) Поэтому заморачиваемся далее. И пишем свой плагин, который будет перечислять наши требуемые метаданные и вызывать какую-то нами определяемую процедуру.
И вот плагин написан (кто не в курсе, это обычная внешняя обработка, только с определенными типовыми методами). Называется ИтераторМетаданных. Его интерфейс описан далее.
Для построения дерева можно и не заполнять реквизит ДопустимыеМетаданные. В этом случае дерево будет заполнено максимальным количеством метаданных. Для этого используется приватная функция плагина ВсеКоллекцииМетаданных().
Пишем тесты
Вариант 1. Тест на чтение Не-Администраторами
Этот вариант задумывался как раз изначально. И, может быть, чуть сложнее, чем будет следующий вариант. В этом тесте будем использовать метод Итератор.Перечислить(. ).
В стандартном методе обработки тестирования проинициализируем Итератор:
Посмотрим еще раз на интерфейсы callback-процедур для метода Итератор.Перечислить(. ) и напишем один интерфейсный метод. Он будет отвечать и за обработку разделов, и за обработку объектов метаданных:
И самый конечный метод, который будет тестировать объект метаданных:
В этом методе используется переменная модуля ПривилегированныеРоли. Это Соответствие, которое заполняем ролями (Объект метаданных: Роль), обладающими расширенными полномочиями на чтение. Инициализируем и заполняем переменную также в стандартном методе Инициализация. Здесь этот код показывать особого смысла нет. См. в исходниках.
Вариант 2. Тест на проверку значений свойств РежимУправленияБлокировкойДанных
Как уже писал, это больше «академический» тест. В реальных разработках он будет иметь ценность лишь для конфигураций, которые находятся в стадии перевода с одного режима управления блокировками на другой.
Код уже не так интересен, и будет расположен в спойлерах.
Опять в стандартном методе обработки тестирования проинициализируем Итератор. Но уже немного по-другому.
А теперь для построения дерева тестов, воспользуемся функцией Итератор.ДеревоМетаданных().
Фирма «1С» выложила комплект автоматизированного тестирования 1С:УХ
На странице публикации релизов конфигурации «1С:Управление холдингом» появилась возможность скачать тесты для автоматизированного тестирования на базе фреймворка Vanessa Automation. Разработчики пригласили всех заинтересованных присоединиться к развитию проекта.
Тесты для 1С:УХ уже доступны для скачивания
В телеграм-канале, посвященном новостям проекта Vanessa Automation, появилось сообщение о публикации пакета тестов для прикладного решения «1С:Управление холдингом». Скачать комплект тестов для автоматизированного тестирования можно уже сейчас в сервисе «1С:Обновление программ».
Комплект содержит четыре папки со сценарными тестами:
Обработка для формирования дымовых тестов
По мнению разработчиков автотестов для 1С:УХ, smoke-тесты на открытие форм могут покрывать до 7% кода конфигурации. Например, таким образом можно обнаружить ошибки, связанные с правами доступа, или ошибки переноса модификаций, если при разработке используется несколько хранилищ конфигурации.
Однако проблемой может быть то, что не все формы в конфигурации предназначены для интерактивной работы.
Чтобы тестирование было действительно автоматизированным, предлагается использовать специальную обработку.
Обработка анализирует все метаданные конфигурации, собирает сведения о формах, добавляет все необходимые исключения и на выходе автоматически формирует дымовой тест под конкретный релиз конфигурации.
Пример финального отчета автотеста, полученного с помощью в Яндекс Allurе. Источник: Youtube-канал «1С:Управление холдингом»
Кроме того, есть возможность сформировать набор дымовых тестов только для измененных относительно конфигурации поставщика объектов – таким образом можно получить «быстрые» дымовые тесты именно для доработанных объектов конфигурации.
Сценарные тесты для создания НСИ и подсистем «Бюджетирование» и «Казначейство»
Наибольший интерес при автоматизации тестировании представляют все же сценарные тесты.
На данный момент в комплекте тестирования доступны тесты для создания основных справочников: контрагентов, номенклатуры, пользователей и тому подобных – всего более 20 сценариев. Предполагается, что эти тесты будут использоваться для дальнейшего развития, и выступать в качестве базовых для проверки различных частей конфигурации.
Такая работа уже проделана для подсистемы «Бюджетирование» – в папке VA-Tests-UH31-Budget опубликовано 10 фича-файлов, содержащих в общем количестве более 90 сценариев тестирования для данного функционального блока.
Аналогично – в папке VA-Tests-UH31-Treasury опубликовано более 35 готовых сценариев для блока «Казначейство».
Предполагается, что по мере развития и появления новых сценариев, все они будут доступными для сообщества.
Что будет дальше
Планируется, что в дальнейшем публикуемые тесты будут актуализироваться для каждого релиза, а также охватывать все больше и больше прикладных задач. При этом разработчики подчеркивают, что открытый формат проекта накладывает некоторые ограничения на работу с публикуемыми файлами. Например, все тесты предлагаются к использованию «как есть», без гарантии и поддержки.
Однако у открытой модели взаимодействия есть и преимущества: «Вы можете присылать свои сценарии тестирования нам, и если они будут работать в типовой конфигурации и выполняться в рамках единого пространства нормативно-справочной информации, мы включим ваши тесты в регламентное тестирование конфигурации, и вы получите гарантии того, что ваши сценарии будут проверены при выпуске очередного релиза» – рассказал Виталий Онянов, разработчик продуктовой линейки «1С:Управление холдингом».
Очень странный комментарий. Откуда по вашему взялись эти тесты? Советую прежде посмотреть приведенный в новости доклад.
(9)
Все верно говорите. Поэтому мы используем такой сценарий тестирования:
1. На чистой базе (из поставки) прогоняем тесты по созданию НСИ.
2. Если тесты прошли успешно, делаем бэкап базы.
3. Для каждой из подсистем в пустую базу загружается последний удачный бэкап с НСИ и прогоняются тесты данной подсистемы.
Как-нибудь об этом тоже расскажем.
Конечно может быть работ и делается много в направлении тестирования типовых конфигураций, но работая с 1С ERP уже свыше 3-х лет, а до этого с разными её так сказать частями типа ЗУП 3.Х и БП 3.Х могу сказать одно, как было дочерта ошибок так и остаётся, и как было невозможно быстро решить проблему через службу поддержки 1С, так ещё все хуже стало, буквально вымогают тестовые примеры из пользователей даже в таких ситуациях, где явно видно, что алгоритм написан так, что не делает проверку деления на ноль и тут опа ситуация мега редкая и идёт деление на ноль, а ты понимаешь чтобы тебе такое же воспроизвести, ты должен ввести сотни документов в демо базу, чтобы 1С поверили что у тебя там действительно деление на ноль происходит.
Про деление на ноль я вспомнил в контексте общих модулей работы с фискальным оборудованием, долго доказывал 1С, что там есть деление на ноль. Казалось бы ну вот там та где фискальные операции там та вообще все тестами должно быть покрыто, но нет. Да и зачем я должен доказывать что там нет проверки деления на ноль если это очевидно и так просто при прочтении кода программы.
Последний случай, что я писал в 1С и видео записывал был про бесконечный цикл возникающий в Олнай взаиморасчетах.
Показал 1С картину сложившуюся в регистрах.
Показал какие документы корректировки регистров сама ERP создала, показал и рассказал, что программа своими корректировками сделала минуса в регистре неком и получала срез данных с минусами (так к слову через несколько месяцев прога ещё сделала корректировки и убрала минуса), и когда там в этом срезе есть минуса алгоритм тупо не учитывает эту ситуацию и не размазывает платежи по отгрузкам, в итоге тупо уходит в бесконечный цикл.
На ERP 2.4 любой документ проводимый, что хотел подвигать взаиморасчёты и у которого данные брались очень «удачно» в том промежутке где были минуса, все зависали и насиловали сервер бесконечным циклом ну и естественно так как блокировка управляемая, то по этому контрагенту по этому же договору вообще ничего провести было нельзя.
Хз как ситуацию разрешит 1С, нам же пришлось грохнуть документы корректировки и перезакрывать периоды из черти откуда.
Если 1С так и дальше будет относится к клиентам оплачивающим ИТС, которые вот на блюдечке приносят информацию об ошибке, но с них требуют буквально доказательную базу, то хоть трижды обложись тестами, 1С это не спасет.
1С on demand – скажи «нет» постоянным билд-агентам
Давайте начнем с того, что представим, что мы пытаемся разрабатывать наше решение качественно, пишем для него тесты и запускаем их на выполнение перед каждым релизом.
Какие тесты вообще могут у нас быть?
Тесты условно можно разделить на три группы:
Smoke-тесты (дымовые тесты). Это какие-то обработки или скрипты, которые выполняют рутинные действия над вашей конфигурацией – открывают все формы, пытаются провести все документы. На основании этих действий вы можете понять, есть у вас какие-то ошибки в базовой функциональности или нет.
Модульные тесты служат для проверки маленьких компонентов системы. Например, проверить что вызов функции с определенными параметрами вернет ожидаемый результат.
BDD или сценарные тесты. Если говорить про 1С, то чаще всего под сценарными тестами подразумевается нажатие кнопок на интерфейсе и проверка того, что на форме отображаются правильные данные – например, что документ провелся корректно, без сообщений об ошибок, всплывающих окон и т. д. Но это не всегда так. Есть классический пример сценарного теста выглядящий так: «Если у меня на счету 300 долларов и я подхожу к банкомату и пытаюсь снять 200 долларов, тогда банкомат дает мне 200 долларов наличными». Это тоже сценарий, все это тоже можно автоматизировать и переложить в тесты.
Проблемы при запуске тестов на рабочей машине
Какие могут быть проблемы, когда вы пытаетесь запустить эти тесты?
Когда вы на своей рабочей машине запускаете тестирование с помощью какого-либо фреймворка (например, это может быть Vanessa Automation), и параллельно пытаетесь писать код в своем любимом редакторе, то в какой-то момент – бац! У вас всплывает модальное окно, которое вы не можете закрыть, и вам приходится выполнять какие-то действия над ним, чтобы продолжить свою работу. Такие проблемы очень часто отвлекают. Ладно бы это всегда были просто окна, но могут быть вообще непонятные артефакты – куски выпадающих списков, отдельные кнопки, прорисовывающиеся сквозь ваш интерфейс.
Кто хоть раз пытался запустить на своем компьютере несколько экземпляров какого-либо тестового фреймворка, сталкивался с тем, что они начинают друг другу мешать. Несколько Vanessa Automation начинают воевать друг за друга – тест-менеджеры цепляют чужие тест-клиенты, инструменты снятия скриншотов захватывают не те окна.
Также могут быть проблемы из-за взаимодействия с сетевыми интерфейсами.
Через некоторое время вы начинаете выглядеть как этот котик. Вас все бесит, у вас ничего не получается. Это начинает очень сильно напрягать, и вы начинаете думать о том, что нет смысла пытаться масштабироваться, потому что даже на вашей текущей локальной машине все работает очень плохо.
Каким образом эту проблему можно решить?
Docker. Решение проблемы путем изоляции
Первый, и, наверное, самый простой вариант – это попытаться изолировать различные экземпляры запущенных приложений.
Есть расхожая шутка о том, что любую проблему вашего приложения можно решить, поместив его в Docker:
продалбываете сроки – запихните приложение в Docker;
не понятен список задач по проекту. Думаю, вы поняли общий смысл.
Что вообще такое Docker? Docker – это один из инструментов виртуализации.
Виртуализацию глобально можно разделить на два способа реализации.
Первый – это виртуальные машины. На самом нижнем уровне у вас есть какое-то железо, на этом железе стоит операционная система с гипервизором, который занимается тем, что запускает новые операционные системы, в которых уже выполняются ваши клиентские приложения.
Второй вариант – это контейнеризация. Мы убираем слой гипервизора и заменяем его на слой оркестратора контейнеров, работающих непосредственно поверх операционной системы. В качестве такого средства можно использовать движок Docker. И уже этот движок запускает отдельные изолированные экземпляры вашего приложения с необходимым окружением, необходимыми библиотеками, но без полноценного эмулирования операционной системы..
Docker Swarm. Реализация масштабирования
У Docker есть довольно простая встроенная возможность объединить несколько узлов, несколько ваших машин в так называемый Docker swarm cluster.
Менеджеры соединены с воркерами, которые выполняют задачи – по сути, запускают контейнеры, в которых выполняются приложения, скрипты и т. д.
Но все мы знаем, что все системы первоначально запускаются на локальной машине (до того, как у вас есть сервера), поэтому в самом простом варианте Docker Swarm у вас есть один менеджер и один-два воркера. Зачастую и воркеров нет, и вы все задачи запускаете сразу на менеджере. Docker Swarm такой режим тоже поддерживает.
Создать docker machine и включить ее в docker swarm cluster несложно – это можно сделать с помощью доступной на GitHub утилиты docker-machine, которая позволяет буквально в два скрипта создать docker swarm cluster и подключить к нему новую машину.
После создания docker machine вы также получите набор ключей и сертификатов, чтобы обеспечивать доступ и управление созданными docker machine с использованием TLS-аутентификации.
Те, кто пользуются Docker for windows, могли заметить в настройках системы галочку «Expose daemon on tcp://localhost:2375 without TLS» (публиковать службу на порту 2375 без TLS).
Система Cloud Provider. Агенты по запросу
Следующая технология, которая поможет нам в масштабировании – это система Cloud Provider.
Я думаю, вы слышали о Google Cloud, об Amazon Cloud – это некая система, в которую вы можете отправить запрос вида: «Дай мне виртуальную машину на два ядра и 4Гб оперативной памяти». Происходит некая магия, и через некоторое время вы получаете либо удаленный доступ к только что созданной виртуальной машине по SSH или RDP и можете начинать с ней работать.
Этот же подход Cloud Provider можно применять на вашем сервере сборок. Например, на Jenkins. У него есть довольно много вариантов подключения различных провайдеров – будь то просто Amazon, Google, Kubernetes или просто docker.
Схема работы с облачным провайдером несколько меняется, но смысл остается тот же. Jenkins отслеживает ваши задания на сборку. Под эти задания выделяет вам build-агента и на этом build-агенте начинают выполняться задания.
Docker Swarm plugin.
Если мы объединим концепции Cloud Provider и Docker Swarm и попытаемся применить ее к Jenkins, то мы можем найти плагин под названием Docker Swarm.
Его конфигурирование довольно простое – в настройках Jenkins появляется новая закладка, в которой вы указываете:
Docker Host URI – где у вас живет master вашего docker swarm cluster;
Server credentials – параметры подключения к нему.
И все, для подключения больше ничего не нужно.
Параметры подключения – это TLS-ключи и сертификаты, которые требуются для поднятия защищенного соединения. Файлы, которые создались после инициализации docker machine, вы можете положить в сохраненные значения и секреты Jenkins и использовать для авторизации.
Что можно сделать, когда у вас есть такой Cloud Provider?
Для начала вы можете запустить базовый агент на основе образа eeacms/jenkins-slave-dind (Docker in Docker), в котором можно выполнить произвольные команды, запустить другие docker-контейнеры или собирать docker-образы, в том числе для 1С.
Самое главное – это указать правильные параметры запуска. Страшный скрипт, который нарисован в центре, генерируется автоматически, не нужно его запоминать. Его можно подсмотреть в справке, доступной по нажатию на кнопку с синим знаком вопроса справа от поля, и просто скопировать.
Конечно же, вы можете использовать Docker, чтобы запускать в нем тесты. Вы можете создать docker-образ с 1С нужной вам версии, указать, его в качестве build-агента в настройках облачного провайдера docker swarm, настроить метку агента (например, под версию платформы). И теперь ваши тесты будут запускаться в Docker, причем в агенте, который будет подниматься только на тот промежуток времени, когда он вам нужен.
Сборочная линия Jenkinsfile в Docker для 1С
Как может выглядеть сборочная линия для 1С, которая запускается в Docker?
Она будет выглядеть примерно так же, как и любая другая сборочная линия, только вам нужно перед этим решить три вопроса.
Вам нужно разобраться с тем, какие данные нужно передавать между различными шагами вашей сборки. Если вы работали с постоянным build-агентом, вы могли привыкнуть к тому, что если вы обратитесь по пути C:\jenkins\artifacts\somedata\file – то вы этот файл оттуда достанете. В случае Docker у вас такой возможности не будет, потому что у вас маленький изолированный контейнер, который ничего не знает про окружение, на котором он запустился, и про то, куда он может достучаться. Эту проблему нам могут помочь решить различные шаги архивации для передачи артефактов между шагами и между сборками.
Второй момент – это работа с внешними ресурсами. Docker обычно запускается в Linux-окружении на Linux-ядре, и в Linux есть определенные особенности по настройке сетевых путей. Если вы работаете с Windows, вы открываете проводник, пишете //ИмяКомпьютера/СетеваяПапка и она у вас сразу открывается. Если у вас есть доменная авторизация, вам даже никакой логин/пароль вводить не нужно. А в случае Docker вам нужно лезть в файлы с конфигурацией сетевых устройств, либо в файлы с конфигурацией автомонтирования и там прописывать пути, куда нужно стучаться, и куда это нужно монтировать, и параметры авторизации, и т.д. Одним из простых способов решения этой проблемы являтеся установка перед вашими статичными внешними ресурсами (внешними файлами, которые вам нужно вытащить) простенького HTTP-сервера (например, Nginx или Apache, если вы умеете его конфигурировать, или даже IIS), который и будет отдавать эти старичные данные по HTTP.
И третье – это, конечно же, нужно написать Dockerfile для 1С.
Сама сборочная линия выглядит довольно привычно для тех, кто хоть раз ее писал для 1С.
Мы говорим о том, что наша сборка выполняется на каком-то определенном агенте. В данном случае используется метка с версией платформы. Такую метку мы задали для нашего build-агента с docker-образом 1С.
На следующем шаге в этом примере организуется контроль качества.
Преимущество агентов, поднимающихся по запросу – это то, что вы можете параллельно запускать несколько шагов или даже разных сборок. В примере выше параллельно запускается несколько шагов:
на шаге «syntaxCheck» мы эту информационную базу разархивируем – кладем в определенный каталог и выполняем дальнейшие операции – например, запуск синтаксического контроля, который делает конфигуратор, но с выводом информации в формате JUnit, чтобы красиво отображать ее в Jenkins.
вы можете сразу запустить сценарные тесты;
вы можете запустить любое количество других шагов, начиная от модульных тестов, заканчивая любой автоматизированной операцией над вашим решением.
Все это можно делать параллельно, и все это не будет мешать друг другу, даже если будет запускаться физически на одной машине. Конечно же при условии наличия свободных ресурсов.
Сами задачи по архивированию и разархивированию – это тоже штатная функциональность Jenkins, просто упакованная в функции-обертки без лишних параметров. Это архивация каталога, где лежит информационная база, и помещение его в stash – специальное хранилище, которое можно использовать для передачи данных между шагами.
Разархивация – это получение файла из stash и его распаковка в папку с информационной базой.
Проблемы самостоятельного создания Dockerfile для 1С
С Dockerfile несколько сложнее. Есть несколько проблем, к которым нужно быть готовым, когда вы начинаете решать задачи построения Docker-образа для 1С.
Так как Docker – это в первую очередь система, которая применяется на Linix-машинах, вам нужны какие-то базовые знания Linux. Вам не нужно знать детально о том, как работает ядро, как собираются модули, детально разбираться в процессах сбора библиотек из исходников. Вам нужно понимание базовых команд, переходы между каталогами, копирование файлов, перемещение, переименование, запуск приложений и т.д.
И третье – это зависимости. В случае 1С, зависимости – это очень сложная штука, потому что, даже несмотря на то, что 1С имеет пакетный режим запуска, чтобы она запустилось в Linux, на машине должно быть установлено очень много дополнительных библиотек. Про это попозже чуть подробнее поговорим.
Готовый Dockerfile для 1С
К счастью, проблемой помещения 1С в Docker занимается довольно много людей. В частности, этой проблемой начала заниматься наша компания. Мы развиваем проект на GitHub под названием onec-docker от пользователя jugatsu.
Мы взяли его разработку за основу и развили ее в своем форке https://github.com/firstBitSemenovskaya/onec-docker. Часть доработок переносится в апстрим, к jugatsu, часть остается в форке, но главное, что все доработки доступны и открыты.
Если вы зайдете на страницу репозитория на GitHub и переключитесь на ветку feature/first-bit, то вы увидите скомбинированный результат работы jugatsu и нас по тому, как завернуть 1С в docker и как подключить ее к Jenkins.
Любая работа с платформой начинается с вопроса: откуда взять дистрибутив? Есть несколько подходов к этому – вы можете положить дистрибутив в локальный каталог, а потом его копировать, либо же вы можете (кодом) зайти на сайт releases.1c.ru и оттуда скачать релиз (естественно, у вас должны быть параметры авторизации и понимание того, какой тип клиента вы хотите установить).
В репозитории есть скрипт, который по переданным аргументам скачает в ожидаемую папку все дистрибутивы платформы – на слайде показан вариант скачивания платформы для debian-систем.
Следующий шаг – установка зависимостей и 1С. В этих образах автоматически ставятся все зависимости, описанные на ИТС, а также дополнительные зависимости, обнаруженные jugatsu и нами.
Вам всего лишь нужно будет выполнить команды по сборке этого образа и по установке клиента 1С – на слайде показано, как стандартным дебиановским приложением dpkg устанавливается сервер, клиент и общие зависимости.
1С – штука сложная, и помимо тех зависимостей и странных библиотек, которые нужны для работы, ей еще нужно графическое окружение. То есть, даже несмотря на то, что чаще всего вы хотите просто запустить конфигуратор и выгрузить, например, конфигурацию в файлы, или выгрузить саму информационную базу в виде dt-ника, 1С все равно нужно поднятое графическое окружение.
Эта задача здесь также решена через xvfb (X virtual framebuffer) и окружение xfce4. Вы можете подключиться к контейнеру через любой vnc-клиент и посмотреть, что же конкретно происходит в моменты прохождения тестов.
Все конфигурационные файлы по подключению подсистемы для графического интерфейса лежат в репозитории и вам ничего дополнительно конфигурировать не нужно.
Так как мы пытаемся запустить нашу 1С-ку на Jenkins, нам нужно к этому Jenkins как-то присоединиться. А поскольку агент Jenkins – это приложение, написанное на Java, поэтому для работы вашего агента в docker-контейнере должна быть установлена Java.
Эта задача здесь тоже решена:
скачивается Java 13-й версии (дистрибутив от AdoptOpenJDK), хотя в принципе достаточно и 8-й версии, но 8-я потихоньку устаревает, поэтому идем вперед;
устанавливаются дополнительные зависимости для Java;
и ставится сама Java.
Следующий шаг – это Mono (среды исполнения, необходимой для работы OneScript) и дополнительных зависимостей.
После этого скачивается менеджер версий ovm, который устанавливает сам OneScript.
И заключительным шагом ставятся библиотеки для OneScript – это gitsync, vanessa-runner, add – то, что обычно используется для сборки и тестирования на Jenkins.
После выполнения всех этих шагов у вас получается образ, в котором есть:
Java и настройки для подключения к Jenkins;
OneScript, позволяющий запускать тесты, gitsync и т.д.
В любом Dockerfile есть такое понятие, как «Точка входа». Это тот скрипт, который будет исполняться, когда вы запускаете docker-контейнер.
В случае этого образа точкой входа является инициализация графической подсистемы и подключение к Jenkins. Автоматически скачивается файл для подключения в качестве агента. Конфигурируется. Все переменные среды автоматически передаются самим сервером Jenkins при запуске контейнера. И вам ничего дополнительно настраивать не нужно.
Сборка и хранение Docker-образа
Собранные образы нужно где-то хранить. Вы, конечно, можете использовать бесплатное хранилище hub.docker.com, но нужно помнить, что вы не имеете права распространять дистрибутивы платформы, соответственно, вам нужно будет эти образы делать приватными и закрывать логином/паролем. При этом у hub.docker.com есть лимит на количество приватных образов. Если же вы пользуетесь, например, GitLab, то у GitLab есть собственное хранилище Docker-образов, в котором вы можете разместить все ваши собранные образы и иметь историю по версиям и по сборкам.
Сборку образов вы можете реализовать с помощью скриптов. Данный скрипт, например, делает docker build, передает все нужные аргументы командной строке и на выходе отправляет собранный docker-образ в ваше хранилище образов.
На слайде выделена вторая часть скрипта, которая позволяет собрать в этом репозитории все слои, которые нужны для 1С, а также слои, которые используются для хранилища и Apache.
Последовательность и возможные способы комбинации слоев вы можете подсмотреть в файле Layers.md в корне репозитория.
Естественно, эту сборку можно автоматизировать. На сервере сборок можно создать отдельную задачу, которая и будет заниматься сборкой нужных образов.
В Jenkins есть такое понятие, как параметризируемая сборка – сборка, которой на вход помимо самого скрипта передаются дополнительные параметры, которые пользователь может указать в пользовательском интерфейсе. Например:
версия платформы 1С:Предприятие, которую вы собираете;
путь к docker registry – информация о том, куда этот образ нужно отправлять;
дополнительные флаги сборки
И на выходе вы по одной кнопке можете, устанавливая и снимая те или иные галочки, и задавая параметры, автоматически примерно за 45 минут (среднее время сборки на нашем сервере) получить готовый Docker-образ. Аналогичным образом можно собрать образы с EDT на борту для запуска расширенной валидации или сбора покрытия.
Схема работы
Каким же образом будет выглядеть ваша система, если у вас получится все это запустить?
Во главе системы располагается сервер сборок (Jenkins), который:
собирает и получает информацию о собранных 1С-ных образах из Docker Registry;
запускает на подключенном Docker Swarm кластере агенты для сборочной линии, на которых выполняются ваши тесты.
Бонус. Оркестрация серверами хранилищ
И в качестве бонуса – я бы еще хотел сказать про сервер хранилищ.
Проблема с доступом к сетевым ресурсам по UNC-путям чаще всего первым делом стреляет на хранилищах. Мы привыкли к тому, что хранилище – это файловая шара, которая под windows подключается без каких-либо проблем, вы просто указываете в конфигураторе каталог размещения //ИмяСервера/СетеваяПапка и все работает.
В случае Linux и Docker вы такую штуку сделать не сможете, потому что вам этот каталог, опять-таки, нужно сначала смонтировать.
Решением этой проблемы является поднятие где-то у вас в контуре сервера хранилища с доступом по HTTP.
И эту задачу вы тоже можете решить с помощью Docker, собрав соответствующий Docker-контейнер (образ crs – сервер хранилищ).
Поверх сервера хранилища устанавливается Apache с настройкой всех нужных конфигурационные файлов и публикации (образ crs-apache).
Мы сейчас работаем над тем, чтобы представить довольно красиво и просто конфигурируемое решение на базе helm chart, которое позволит каждое ваше хранилище развернуть внутри Kubernetes с помощью одного скрипта, автоматически конфигурирующего все, что нужно. Конечная цель – это получить что-то вроде crs.mycompany.com/ИмяГруппы/ИмяПроекта.
На этом у меня все, спасибо за внимание.
Вопросы:
Сколько у тебя месяцев ушло на то, чтобы все это осознать и освоить?
Почти весь последний год (мы начали в феврале 2019 года) мы занимаемся переносом в Kubernetes наших внутренних сервисов. Сейчас у нас там работает несколько систем – GitLab, SonarQube, Redmine, Jenkins. После того как мы подняли там инфраструктуру управления проектами и общую инфраструктуру разработчика, следующим шагом стала задача масштабирования тестов (тестовых контуров и запусков). Конкретно этой задачей мы занимаемся с конца декабря 2019. И этот доклад – это, по сути, компиляция тех доработок репозитория jugatsu, которые пришлось сделать, чтобы запустить это в Jenkins (с декабря 2019 по март 2020).
Почему Docker Swarm, раз у вас есть Kubernetes?
Docker Swarm и его плагин для Jenkins оказался очень удобной отправной точкой в условиях ограниченных серверных ресурсов. К Jenkins (а точнее к Docker Swarm Cluster) подключено несколько обычных машин разработчиков, и важным ограничением стал вопрос простоты и скорости настройки новой машины. Подключить рабочую станцию к сворму оказалось намного проще и быстрее, чем разворачивать на ней полноценный узел Kubernetes. Возможно в будущем мы откажемся от использоваться Docker Swarm и переведем 1сные сборки в Kubernetes, но пока нас устраивает текущее решение.
Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Kazan. Больше статей можно прочитать здесь.