CI/CD для 1С: как упростить себе жизнь

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

У нас было то же самое, имелось две базы:

• продуктовая (База1Предприятие) с данными, в которой все обработки, отчеты и ПФ помещены как дополнительные в справочник ДополнительныеОтчетыОбработки;
• разработческая (База2Разработка) пустая без данных, но все обработки, отчёты и печатные формы хранятся встроенными в конфигурацию подключенную к Хранилищу_Конфигураций.

В остальном обе конфигурации с точки зрения метаданных идентичны. Разработка, учет версий, изменения ведутся в База2Разработка и потом вручную после тестирования разработчик или тестировщик обновляет справочник в База1Предприятие.

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

Почему не перейти на Git? Наша конфигурация достаточно старая и использует обычные формы, поэтому переход на EDT и Git посчитали сложным из-за необходимости переработки кода.

Какое решение? Автоматизация через CI/CD. И в этой статье я покажу, как настроить конвейер непрерывной интеграции и доставки для 1С на примере Jenkins. В результате получится автоматический процесс, который сам обновляет продуктовую базу при изменениях в разработческой.

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

/srv/docker_apps/

   jenkins/

       - Dockerfile

    scripts/

        - install_plugins.sh

    init.groovy.d/

        - basic-security.groovy

    settings/

        - settings.xml   # Maven settings.xml - не обязательно для 1C

    data/                # volume для Jenkins home

```groovy
pipeline {
    agent { label 'windows' }
    stages {
       stage('Обновление конфигурации 1С') {…. }
       stage('Convert XML to Binary') {…. }
       stage('Deploy to production OneC Base') {…. }
       //Другие стадии и настройки
    }
}
```

Скрипты работы с 1С

Во вложенном архиве представлены готовые скрипты, которые выполняют следующие действия:

1. Обновить разработческую базу из Хранилища_Конфигураций и выгрузить конфигурацию в файлы XML
2. Заменить теги в файлах XML и конвертировать их в *.epf, *.erf
3. Вызвать обработку 1С с параметрами запуска для развертывания в продуктовой База1Предприятие.

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

Преобразование XML в .epf, .erf.

После выгрузки конфигурации 1С в файлы имеем файлы xml в директориях \DataProcessors и \Reports. Если сразу попробовать в Конфигураторе создать новую пустую обработку/отчет и выбрать Загрузить из файлов напрямую указав файл xml, то 1С не дает этого сделать и выдает ошибку: "Ошибка загрузки документа. Отсутствует контейнер метаданных по причине: Отсутствует контейнер метаданных."

Давайте используем особенность 1С: если в XML-файле заменить теги <DataProcessor> на <ExternalDataProcessor> (или <Report> на <ExternalReport> для отчётов), то скрипт успешно конвертирует их в .epf или .erf.

См. пример конвертации xml файла в *.epf.

При этом, если Вы попробуете сделать замену тегов XML и загрузку через Конфигуратор вручную, то работать будет через раз - причину мне не удалось найти. И да ошибки, которые могут появляться при ручной загрузке в Конфигураторе не оказывают влияния на успешность конвертации при работе через скрипты.

Обновление продуктовой базы

Запуск обновления в справочнике продуктовой базы производится путем вызова скрипта с передачей ему на вход параметров запуска 1С, с указанием пути к файлу новой версии обработки/отчета .epf, .erf и КодаОбработки в справочнике ДополнительныеОбработки (название измените для своей конфигурации), которую нужно обновить.

Примечания:

• Проверка что загружаемая версия больше текущей не рассматривается здесь для упрощения, можно легко реализовать дополнительно.
• У служебного пользователя, под которым в продуктовую База1Предприятие будут загружаться обновления, нужно убрать ограничение “Защита от опасных действий” для предотвращения лишних сообщений.

Что в приложенном файле:

1. Dockerfile - файл для запуска контейнера Jenkins в Докере
2. Jenkinsfile - Groovy скрипт для Jenkins Pipeline, включая рассылку в мессенджер после выполнения всех стадий
3. install_plugins.sh - скрипт установки плагинов Jenkins
4. basic-security.groovy - задание логина/пароля для входа в Jenkins
5. 1_updateConf.cmd - скрипт обновления конфигурации 1С из хранилища и выгрузки в файлы XML
6. 2_getVersionFile.ps1 - получает из файла XML версию обработки/отчета для различных интересных сценариев работы
7. 3_convertFile.ps1 и 3_ReplaceXML.vbs - заменяет теги в XML файлах и конвертирует их в *.epf, *.erf
8. 4_insert.ps1 - скрипт запуска 1С для обновления обработки в продуктовой базе
9. UploaderSimple.epf - Обработка 1С, которая вызывается при запуске 1С:Предприятия для обновления версии в целевой продуктовой База1Предприятие (имя справочника в обработке адаптируйте под свою конфигурацию).

В заключение

Спасибо, что дочитали до конца. CI/CD для 1С это спасение от рутины и ошибок. С этим конвейером вы сэкономите время, повысите надёжность и ускорите разработку. Несмотря на то, что в примерах я использовал Jenkins и Java-агент, основная сила решения заключается в "чистых" скриптах. Всё, что вам нужно это командная строка и 1С. Никаких EDT, Git, БСП, тяжёлых зависимостей, плагинов, других языков или "кошмаров библиотек": вы можете запускать CI/CD-конвейеры просто по расписанию. Подход полностью конфигурируемый, легко адаптируется под любую инфраструктуру и сохраняет простоту сопровождения. Идеально подходит для устаревших конфигураций с обычными формами и не требует от команды глубоких знаний DevOps.

В дополнение, подробно описан нестандартный процесс конвертации XML-файлов в бинарные форматы 1С (*.epf, *.erf) с заменой тегов, что позволяет автоматизировать задачи, которые обычно требуют ручного вмешательства. Этот подход может быть полезным даже для тех, кто уже использует другие CI/CD-системы.

Скачивайте архив с готовыми скриптами и настройками - там всё готово для старта. Если статья была полезна, ставьте плюс, чтобы не потерять.

Возможно Вас заинтересуют другие публикации:

• SFTP для 1С
• Фоновые задания: быстро получить большие данные в 1С
• Создание пользователей системы взаимодействия
• Работа из 1С с API PayPal
• Гарантированный обмен 1С через Microsoft MSMQ
• Чтение файлов PDF из 1С
• Программное открытие отчета