Простейший Jenkins Pipeline для 1C
В прошлой заметке был установлен Jenkins и настроен простейший конвейер сборки. Рассмотрим другой вид задач Jenkins — Pipeline. Данный вид задач дает красивое представление выполнения шагов задачи сборки. В интернете большое количество полноценных инструкций настройки этого вида задач. Рассмотрим простейший вариант, без использования параметров и GIT.
Чтобы использовать Pipeline нужно установить плагин Pipeline и плагины, с ним связанные.
Cоздаем новую задачу Создать Item -> Pipeline и вводим название. Важно чтобы в названии НЕ БЫЛО РУССКИХ БУКВ. Иначе не будет выполнятся команда bat скрипта.
В разделе Pipeline выбираем вариант Pipeline script и в текстовое поле Script вводим код:
node < stage('Обновление базы из хранилища') < bat '''chcp 65001 "C:\\Program Files\\1cv8\\8.3.17.1989\\bin\\1cv8.exe" DESIGNER /ConfigurationRepositoryUpdateCfg -revised -force /DepotUpdateCfg /UpdateDBCfg /S"СерверПриложений/База" /N"Пользователь" /ConfigurationRepositoryF"ПутьКХранилищу" /ConfigurationRepositoryN"Пользователь" ''' >>
Этот скрипт получает изменения из хранилища конфигурации и обновляет конфигурацию базы данных.
В секции stage описывается отдельный шаг задачи. Сколько будет таких секций столько шагов.
Символ ‘\’ экранируется вторым символом ‘\’, либо заменяется на обратный ‘/’.
Многострочная команда заключается в тройные кавычки — одинарные или двойные.
Чтобы правильно составить командную строку есть помощник, который расположен на отдельной странице Pipeline Syntax. В поле Sample steps нужно выбрать из списка bat: Windows Batch Script. В текстовом поле Batch Script ввести команду и нажать кнопку Generate Pipeline Script. Полученный текст из нижнего поля можно скопировать и вставить в секцию stage скрипта.
Запуск по расписанию настраивается аналогично. В разделе Триггеры сборки нужно установить Запускать периодически и появится поле для ввода расписания.
Cохраняем заполненное задание, а дальше Jenkins сам начнет выполнять заданные действия.
Для запуска сценариев нужен особый режим выполнения команд, поэтому необходимо добавить узел, который будет выполнять команды в интерактивном режиме. Агент узла нужно запускать через командный файл.
Ну и конечно же не забываем про кириллицу, которая точно где-нибудь да встретится. Нужно добавить параметр запуска java «-Dfile.encoding=UTF-8» в строку запуска агента.
Простейший сборочный конвейер 1С+Jenkins
Автоматизация тестирования обязательно должна включать в себя этап автоматизации запуска тестовых сценариев. Самым простым и доступным является система Jenkins.
Чтобы начать использовать Jenkins нужно совсем немного усилий. Самый простой конвейер можно собрать в связке 1С+Jenkins. В интернете огромное количество инструкций по установке Jenkins. Рассмотрим особенности установки на Windows машину, находящейся в сети с доменной аутентификацией.
Первое что требуется это установка JDK. С недавних пор Oracle существенно изменило лицензионную политику. Поэтому для установки можно воспользоваться Liberica JDK https://libericajdk.ru/pages/downloads/
Далее устанавливаем Jenkins, дистрибутив берем с официального сайта https://www.jenkins.io/download/
Jenkins устанавливается как служба, поэтому при установке потребуется указать логин и пароль пользователя, из под которого будет работать служба. При установке можно указать системную учетную запись, а после установки ее можно поменять на нужную уже непосредственно в службе. По умолчанию консоль управления доступна по адресу localhost:8080.
Больше ничего не требуется для того чтобы собрать простейший сборочный конвейер. В самом простом случае можно создать по одной задаче сборки на каждую базу. Одна такая задача может включать в себя неограниченное количество шагов. Например, в одной задаче может быть такая комбинация шагов:
- обновить тестовую базу из хранилища конфигурации
- выполнить синтаксис контроль обновленной конфигурации
- выполнить прогон тестов в обновленной конфигурации
Чтобы создать задачу конвейера нужно выполнить Создать Item -> Создать задачу со свободной конфигурацией. В форме новой задачи в разделе сборка нужно выполнить Добавить шаг сборки -> Выполнить команду Windows.
В поле Команда вводится командная строка, запускающая нужное действие.
Такая строка получает изменения из хранилища и обновляет конфигурацию базы данных:
"ПутьККаталогу1С\1cv8.exe" DESIGNER /ConfigurationRepositoryUpdateCfg -revised -force /DepotUpdateCfg /UpdateDBCfg /S"СерверПриложений\База" /N"Пользователь" /ConfigurationRepositoryUpdateCfg -revised -force /DepotUpdateCfg /UpdateDBCfg /DisableStartupDialogs /DisableStartupMessages /ConfigurationRepositoryF"ПутьКХранилищу" /ConfigurationRepositoryN"ПользовательХранилища"
Если в команде присутствуют русские символы может потребоваться установить нужную кодировку командой chcp. Последовательно добавляя шаги сборки можно получить нужную последовательность действий. Запуск задачи сборки проводит к последовательному выполнению шагов сборки.
Самая простая автоматизация запуска это запуск по расписанию. В разделе Триггеры сборки нужно установить Запускать периодически и появится поле для ввода расписания. Если нажать на синий вопрос справа, то появится подробнейшая инструкция по настройке расписания запуска.
Cохраняем заполненное задание, а дальше Jenkins сам начнет выполнять заданные действия.
Юрий Гончарук. Jenkins на службе 1С
Основная специализация Jenkins – это, прежде всего, CI/CD. Но его можно использовать и для других важных задач: разбора хранилищ, настройки копий баз данных, раздачи прав пользователям, рестарта кластера и проверки кода проектов. Об опыте использования Jenkins для автоматизации рутинных задач 1С-ника на конференции Infostart Event 2021 Moscow Premiere рассказал Юрий Гончарук.
Доклад в виде статьи: https://infostart.ru/1c/articles/1899298/
- Дата
- Дата
- Рейтинг всех уровней
- Рейтинг 1-го уровня
- Древо развёрнутое
- Древо свернутое
Автоматизация при разработке платформы «1С: Предприятие»
В этой статье пойдет речь о том, как мы автоматизируем процессы разработки и тестирования технологической платформы «1С:Предприятие 8». Платформа «1С:Предприятие 8» — набор инструментов для создания бизнес-приложений и среда их выполнения. Это большой (более десятка миллионов строк кода) проект на С++, Java и JavaScript. Над ним трудятся десятки программистов, одновременно разрабатывающие и поддерживающие до 10 различных версий продукта.
Платформа работает на различных версиях ОС и БД:
- ОС: Windows, Linux, macOS
- СУБД: MS SQL, PostgreSQL, IBM DB2, Oracle, файловая СУБД собственной разработки
- Мобильные ОС: Android, iOS, Windows
- Тонкий клиент
- Толстый клиент
- Веб-клиент (Internet Explorer, Microsoft Edge, Chrome, Firefox, Safari)
- Мобильный клиент
Общие задачи автоматизации
Цели, которые мы перед собой ставим:
- Максимально автоматизировать и ускорять рутинные задачи разработки и тестирования
- Непрерывное тестирование с минимальными усилиями на проведение теста
- Добавлять в версию продукта только качественный новый код
- Не ломать старую функциональность
- Приблизить число существенных дефектов в выпускаемой платформе к нулю
- Обнаруживать проблемы на ранних стадиях, чтобы снизить до минимума затраты на расследование и исправление
Одновременная разработка нескольких версий платформы
Мы применяем в своей работе практику Continuous Integration (CI); слияние рабочих копий кода в общую основную ветвь происходит несколько раз в день, после слияния выполняется автосборка и автотестирование измененного проекта. В случае наличия проблем при сборке или тестировании изменённый код возвращается на доработку.
Процессы разработки одной версии платформы
Задачи, стоящие перед CI:
- Сборка
- Серия сборок различного типа и последующее тестирование изменяемых версий, как часть непрерывного цикла. Для ускорения расследования изолированных изменений в результатах тестов мы используем инкрементальную компиляцию – компилируется только то, что изменилось и прямые зависимости. Для полного цикла тестирования сборки собираются полностью. Необходимость и последовательность дополнительных сборок определяется результатами тестирования, предварительный анализ которых автоматизирован.
- Проверка «в стороне» существенных изменений (интеграционные сборки). В случае если инженер считает изменения существенными, он вначале вливает их в отдельную ветку, собирает ее и прогоняет все тесты. При успешном прохождении всех тестов изменения вносятся в основную ветку.
- Максимально быстрое обнаружение ошибок, по возможности в автоматическом режиме
- Автоматизация рутинных действий (анализ дампов, миграция изменений между ветками, регистрация ошибок)
- Регрессионное
- Юнит-тесты
- Интеграционное тестирование
- Нагрузочные тесты
- Визуальные тесты
- Тесты обратной совместимости
- Сценарное тестирование
- В основном функциональное
- сюда же отнесем и ручное тестирование
Для некоторого типа сборок принято правило «10 сбоев», когда серия тестов автоматически прерывается при достижении 10 сбоев в пределах одной серии, чтоб освободить ресурсы для тестирования других сборок/других версий и т.д.
В сборке и тестировании у нас участвует около 70 физических серверов и около 1500 виртуальных серверов.
Инструменты
Jenkins
Мы используем Jenkins в качестве системы непрерывной интеграции. В пиковые периоды он выполняет от 20 сборок платформы в день; на одну полную сборку уходит около 1.5 часов, на тестирование – от 1 часа. Сборка ведется параллельно по архитектурам (Windows, Linux, macOS), каждая сборка – в сотни потоков одновременно. Такой подход несколько лет назад позволил сократить время сборки одной версии платформы со всеми архитектурами с 8 часов до 80 минут, и мы не собираемся останавливаться на достигнутом.
Через веб-сервисы Jenkins интегрирован с нашим таск-трекером, «Базой Задач» (написанном на платформе «1С:Предприятие»), и в случае проблем автоматически заводит ошибки непосредственно в «Базе Задач», прикладывая ссылки на логи и артефакты тестирования. Также Jenkins подготавливает платформу к публикации, при необходимости фильтрует и разбирает дампы.Также Jenkins управляет тестированием, позволяя реализовывать сколь угодно сложные сценарии на произвольных конфигурациях оборудования, в том числе на большом количестве виртуальных машин, а также делает дополнительную работу, например – доставку и установку платформы на 1500 серверов до 70 раз в день.
Apache JMeter
У JMeter есть очень ценное качество – у него низкие требования к оборудованию для эмуляции работы большого количества пользователей. Также JMeter позволяет генерировать смешанную нагрузку в одном тесте – HTTP, SOAP, JDBC, LDAP, SMTP, TCP.
В частности, мы используем JMeter для тестирования производительности кластера приложений и отдельных его компонент, а также для нагрузочного тестирования кластера приложений на большом количестве (до 10 000) пользователей. Для этого тестирования достаточно одного сервера БД, двух серверов 1С и одного сервера нагрузки.
У нас есть 4 стенда для тестирования, на которых тестируются одиночный кластер, кластер в отказоустойчивой и неотказоустойчивой конфигурациях; для тестирования этих конфигураций нам достаточно всего двух физических машин.
Графики производительности от JMeter
Тест-центр
Для более сложного тестирования мы используем наш продукт Тест-центр (входит в состав Корпоративного Инструментального Пакета). Тест-Центр – это конфигурация на платформе «1С:Предприятие 8»; он позволяет описывать многопользовательские сценарии тестирования, автоматически запускать их и контролировать ход их выполнения. Мы запускаем Тест-центр на так называемых конвейерах; один конвейер состоит из 2 мощных физических серверов, на которых расположены виртуальные машины:
- 1 сервер приложений 1С
- 1 сервер БД
- 1 сервер лицензирования
- 40 серверов с клиентскими сеансами
- малые
- средние
- большие
- облачном, для технологии 1cfresh (база с большим количеством сравнительно небольших областей данных)
- КОРП, для крупных внедрений (база большого размера)
- 1С:Бухгалтерия
- Управление нашей фирмой
- Зарплата и управление персоналом
- Зарплата и Управление Персоналом
- 1С:ERP Управление предприятием 2
Для запуска тестов на 10000 пользователей в одной базе используется два рабочих сервера приложений 1С. Каждая конфигурация кластера настраивается автоматически из сотни параметров в начале каждого теста. По сути можно считать, что стенд полностью готовится к работе автоматически, т.к.:
- доставляется платформа
- доставляются скрипты
- настраивается кластер
- загружается база данных
- настраиваются конфигурационные файлы (по заданным параметрам)
- готовятся публикации информационных баз
В ходе проведения нагрузочных тестов мы автоматически собираем и анализируем:
- все ошибки по данным Тест-Центра
- исключения из технологического журнала платформы
- все запросы из технологического журнала платформы
- все ошибки из журнала регистрации
- все замеры выполненных операций с технологической информацией о их выполнении
- все данные по загруженности оборудования
Экран Тест-центра
Еще мы проводим нагрузочное тестирование работы 10 000 пользователей в конфигурации «1С:ERP Управление предприятием 2» на отказоустойчивом кластере с моделированием отказов оборудования, отказов сети, нехваткой памяти, ресурсов ЦПУ и места на диске. Это большой тестовый сценарий, в котором поочередно на протяжении всего теста моделируется зависание серверных процессов 1С, часть процессов «убивается» утилитой taskkill, отключается и восстанавливается сеть и т.д. В рамках тестирования прогоняются пользовательские сценарии работы в разных подсистемах – склад, закупки, продажи, взаиморасчеты и т.д. В нагрузочном тесте ERP проводится около 400 ключевых операций, тест идет несколько часов.
Один из сценариев тестирования ERP (выполняющийся параллельно с другими сценариями)
Сравнение Производительности Конфигураций
Поверх описанных систем работает наш внутренний инструмент – «Сравнение Производительности Конфигураций» (СПК), позволяющий сравнивать производительность:
- разных версий одной конфигурации на одинаковой платформе
- двух версий платформы при работе одной и той же конфигурации
- разных версий БД/ОС с одной и той же платформой/конфигурацией
Мы анализируем как ухудшение показателей, так и улучшение, что может быть симптомом какой-либо проблемы.
Система может использоваться для сравнения
- версий конфигураций,
- версий платформы,
- версий СУБД,
- каких-либо настроек
Под сравнением производительности подразумевается измерение общей производительности конфигураций, среднего времени работы и среднего APDEX по каждой ключевой операции.
Визуальное тестирование
Все вышеперечисленные инструменты эмулируют работу пользователей, вызывая соответствующие методы встроенных объектов тестируемых конфигураций, делая вызовы web- и HTTP-сервисов и т.п. Но также крайне важно тестировать именно то, что реально видит пользователь, особенно пользователь, работающий через веб-клиент (где довольно существенное время может занять отрисовка интерфейса браузером). Мы сталкивались с ситуацией, когда производительность с точки зрения автоматических тестов при переходе на новую версию не менялась, но когда мы сажали человека с секундомером, то он получал одни числа на старой версии, и совершенно другие – на новой. Связано это, в частности, со временем отрисовки графического интерфейса, которое в новой версии по какой-то причине могло поменяться.
Мы написали свой инструмент, позволяющий делать визуальное тестирование практически любого приложения. Инструмент записывает действия пользователя, запустившего приложение, в файл-сценарий. Инструмент также записывает изображение рабочей области экрана. При контроле новых версий клиента сценарии проигрываются без пользовательского участия. При проигрывании сценария инструмент, прежде чем сэмулировать нажатие клавиш или кнопок мыши, ожидает появления такой же картинки экрана (с точностью до пикселя), какая была в записанном сценарии.Инструмент также проводит замеры производительности приложений с точностью до 25 миллисекунд, результаты пишет в лог для дальнейшего автоматического сравнения. В ряде случаев мы закольцовываем части сценария (например, несколько раз повторяем ввод заказа) для анализа деградации времени выполнения сценария. Это тестирование, помимо замера производительности, также позволяет нам быть уверенными, что в новой версии платформы пользователь увидит в тонком клиенте и в браузере те же экраны, что и на предыдущей версии приложения.
Пример запуска сценария по вводу заказа в конфигурации «Управление Нашей Фирмой» — заказ вводится 5 раз; вот реальная скорость работы платформы «1С:Предприятие», если пользователь мгновенно реагирует на доступность интерфейса:
Функциональное тестирование
Мы также активно развиваем функциональное тестирование. Тестируем комбинации основных версий ОС и баз данных, на каждую такую комбинацию у нас есть свой комплект виртуальных машин, весь комплект комбинаций образует один конвейер; автоматизировано добавление новых комбинаций ОС и БД в этот конвейер. Каждый функциональный тест превращается в набор задач, исполняющихся на всех возможных комбинациях; задачи выполняются первыми свободными стендами. Тестируются Конфигуратор (среда разработки прикладных решений 1С), функции встроенного языка, язык запросов и т.д.
При тестировании Конфигуратора мы проверяем большинство команд, доступных в командной строке Конфигуратора. Помимо этого у нас есть специальная библиотека (наружу мы ее не поставляем), позволяющая тестировать внутреннюю логику работы Конфигуратора, доступную только через пользовательский интерфейс, не прибегая к непосредственному UI-тестированию. Таким образом, тестируется большинство функций по работе с расширениями конфигурации, функционал сравнения/объединения и другой функционал Конфигуратора.
Для целей тестирования в этом режиме доступно написание скриптов на языке 1С. В рамках скрипта доступны специальные объекты для целей тестирования. Запуск конфигуратора в этом режиме может совмещаться в одном тесте с запуском клиентского приложения. Это позволяет использовать этот режим не только как средство тестирования конфигуратора, но и как способ настройки тестового окружения.
Eating your own dogfood
Есть ряд наших внутренних инструментов, написанных на платформе «1С:Предприятие», которые мы используем в нашей ежедневной работе. Они работают на самых свежих сборках платформы. Ниже мы расскажем о двух из них – «Базе задач» и «Отчетах сотрудников».
База задач
Наш внутренний таск-трекер, «База задач» — конфигурация, написанная на платформе «1С:Предприятие». Это 21 самостоятельная база (часть баз – рабочие, часть — тестовые) на разных версиях платформы, с разными ОС и СУБД, базы синхронизируются через платформенный механизм обмена данными; версии платформы обновляются ежедневно, на некоторых серверах ставятся экспериментальные версии платформы с отдельными новыми фичами. Закоммиченную новую функциональность платформы можно тестировать на «Базе Задач» уже на следующий день. Разные экземпляры баз работают с разным серверным окружением (ОС, СУБД) и с разными версиями платформы, а пользователи еще и входят с разных клиентов (тонкий клиент, мобильный клиент) и через веб-клиент с разных браузеров. Таким образом, осуществляется тестирование разных версий платформы в разном окружении.
Отчеты сотрудников
«Отчеты сотрудников» — это тайм-трекер для учета рабочего времени, который используют сотрудники отдела разработки платформы «1С:Предприятие». Он работает на самой последней сборке платформы.
«1С:Документооборот»
Типовое решение «1С:Документооборот», которым пользуются все сотрудники нашей фирмы, мы также используем с новыми, еще не выпущенными версиями платформы.
Тесты платформы в прикладных решениях
Наряду с автоматическими визуальными тестами популярных прикладных решений («Бухгалтерия Предприятия», «Управление Нашей Фирмой», «Зарплата и Управление Персоналом» и т.п.) мы проводим ручные тесты: сценарные, визуальные, ручную отработку по тест-плану основных кейсов. После достижения определенного уровня качества платформы мы просим разработчиков прикладных конфигураций перейти на разработку на новой версии платформы и протестировать свои продукты на готовящейся к выпуску версии.
Бета-тестирование платформы партнерами
Некоторые наши партнеры проявляют заинтересованность в использовании ранних, еще не выпущенных версий платформы «1С:Предприятие». Такие партнеры подписывают с фирмой «1С» NDA, получают доступ к сборкам платформы до выхода тестовой версии и имеют возможность использовать самую новую версию платформы в реальных условиях. Это позволяет партнерам на ранней стадии обнаружить проблемы в платформе и быть уверенными, что в релизной версии платформы этих проблем уже не будет. Обращения от таких партнеров по поводу найденных ошибок мы стараемся рассматривать с высоким приоритетом. Кстати, если кто-то из читателей этой статьи захочет принять участие в бета-тестировании платформы «1С:Предприятие» — пишите на CorpTechSupport@1c.ru.
Планы
В планах – переход на Continuous Delivery, на практику, предполагающую постоянную готовность основной сборки к выпуску, чтобы сократить сроки от окончания разработки до выпуска. Для достижения этого мы хотим расширять покрытие тестами, развивать функциональное и нагрузочное тестирование.
- 1С
- erp системы
- программирование
- тестирование по
- 1с:предприятие
- Блог компании 1С
- Тестирование IT-систем
- Анализ и проектирование систем
- Управление разработкой