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

09.06.25

Разработка - DevOps и автоматизация разработки

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

Платные

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование Скачано Купить файл
(только для физ. лиц)
DevOps_Jenkins_OneC
.zip 12,97Kb
5 2 150 руб. Купить

Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний за 2430 руб. в месяц

Оформите подписку на компанию для решения рабочих задач

Оформить подписку и скачать решение со скидкой

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

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

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

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

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

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

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

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

 
Установка и настройка Jenkins

 

Скрипты работы с 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-системы.

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

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

Проверено на следующих конфигурациях и релизах:

  • Управление торговлей, редакция 10.3, релизы 10.3.88.3
  • Управление торговлей, редакция 11, релизы 11.5.22.63

1C CI/CD Автоматизация разработки 1С Jenkins и 1С Непрерывная интеграция 1С Развёртывание обработок 1С XML в EPF XML в ERF Внешние обработки 1С Автоматизация бизнес-процессов DevOps 1C

См. также

Тестирование QA DevOps и автоматизация разработки Программист Пользователь 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.173.37.

2160 руб.

20.01.2022    9362    36    0    

17

DevOps и автоматизация разработки Системный администратор Программист Стажер Бесплатно (free)

Готовим контейнеризированный Microsoft SQL Server в среде Windows

23.05.2025    3715    SerVer1C    35    

32

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) EDT Программист 1С v8.3 Бесплатно (free)

В процессе использования 1С:EDT и репозитория Git для обновлений релизов доработанных конфигураций появилась необходимость в регулярной загрузке конфигураций от вендора 1С в Git-репозиторий. Описанное в статье решение позволяет автоматизировать эту операцию и может быть полезным специалистам, занимающимися обновлениями с использованием 1C:EDT+Git

21.05.2025    2483    ICL-Soft    3    

18

DevOps и автоматизация разработки Программист 1С v8.3 Бесплатно (free)

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

18.09.2024    6555    antonov_av    6    

16

DevOps и автоматизация разработки Бесплатно (free)

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

28.08.2024    12338    yuraid    32    

62

DevOps и автоматизация разработки Программист Бизнес-аналитик Руководитель проекта 1С v8.3 1С:Документооборот Россия Бесплатно (free)

В данной инструкции рассмотрим процесс развертывания приложения на Python с использованием фреймворка Flask и Tesseract OCR в контейнере Docker. Узнаем, как использовать Tesseract в связке с Flask и осуществлять обращения к Tesseract для обработки изображений. Рассмотрим пример обращения к приложению Docker из 1С, в том числе для замещения CuneiForm в старых конфигурациях 1С:Документооборот версии 1.4 и ниже.

20.08.2024    5185    romanichenko    2    

9

DevOps и автоматизация разработки Тестирование QA Программист Пользователь 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Зарплата и Управление Персоналом 3 и версии КОРП: 3.1.30.178.

3240 руб.

05.08.2024    2645    17    1    

11

DevOps и автоматизация разработки OneScript Системный администратор Программист Стажер Бесплатно (free)

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

17.06.2024    10344    bayselonarrend    5    

63
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. ImHunter 338 09.06.25 14:37 Сейчас в теме
Есть ли что-то про расширения?
3. da_1c 193 09.06.25 18:58 Сейчас в теме
(1) Не используем расширения
2. partizand 140 09.06.25 18:28 Сейчас в теме
Неясно, почему разработчики сразу не делают внешние обработки. Их как раз можно положить в гит. Зачем лишняя конвертация.
4. da_1c 193 09.06.25 19:01 Сейчас в теме
(2) Не понимаю вопрос. Вы предлагаете класть в гит бинарники 1с?
5. partizand 140 09.06.25 20:08 Сейчас в теме
Я предлагаю делать сразу то, что будет в рабочей базе - внешние обработки. Это сильно упростит процесс развертывания.
А внешние обработки уже можно закатывать в гит. Есть там такой пункт "выгрузить в файлы" (если вы не в курсе).
А то выглядит это все как автоматизация хаоса.
triviumfan; +1 Ответить
6. triviumfan 102 10.06.25 00:47 Сейчас в теме
(5) тоже не понял зачем эта дополнительная конвертация
7. Peltik2 10.06.25 01:02 Сейчас в теме
(5) если автоматизировать бардак, то получится автоматизированный бардак :)
8. da_1c 193 10.06.25 02:09 Сейчас в теме
(5) Внешние обработки в Git это хорошо, но без гарантированного захвата объектов в хранилище это превращается в хаос, особенно при работе распределённой команды с разницей во времени до 8 часов.
Git не решает конфликтов, если объект не заблокирован, и в таких случаях возникают накладки и теряются изменения. Поэтому мы используем захват объекта в хранилище и храним обработки в отдельной базе через конфигуратор.
А как у вас решается ситуация, если программист просто забудет выгрузить внешнюю обработку в Git? Или если 10 человек одновременно зальют по одной своей фиче в 1 обработку? В таких случаях разруливать будет сложновато.
Для нашей команды текущая схема надёжнее, управляемее и проверена годами использования.
9. yukon 154 10.06.25 08:23 Сейчас в теме
(8) Все отлично разруливается. Количество разработчиков тут не главное.

В хранилище единицей изменения является объект, в git строка, что на порядки (в сотни и тысячи раз) снижает вероятность конфиликта
А при правильном построении процесса разработки и структурировании кода вообще снижает эту вероятность до единичных значений.
10. da_1c 193 11.06.25 03:08 Сейчас в теме
(9) На практике это «всё отлично разруливается» часто просто теория. Мы уже проходили через случаи, когда в одну обработку за ночь прилетало по 5 изменений от разных людей, в разные части одной процедуры, не учитывая доработки друг друга. Мёржи да, теоретически проще. Но если в этих строках разная логика и смысл, а задачи не связаны это уже не мёрж, а ручная реконструкция. Особенно если никто не знал о параллельной работе. Такой якобы «единичный» конфликт может сжечь несколько часов человека уровня выше среднего с хорошим таким окладом.
Git хорош, но он не решает проблему координации и не заменяет контроль объекта. Мы просто предпочитаем процесс, где конфликты не возникают вовсе, а не потом «отлично разруливаются».
11. kastielm368 12.06.25 19:58 Сейчас в теме
Тут многие предлагают везде использовать внешние обработки. А у меня обратный вопрос: зачем вообще использовать внешние обработки и отчеты, если есть расширения, или если тем более на проекте допускается добавление объектов в основную конфигурацию? Наблюдал такое на многих проектах, даже без ci cd. Ведь версионировать проще, дорабатывать проще, и нет путаницы с кучей разных версий одной обработки в каталоге где то на компе у разраба. Например, отчеты и печатные формы при подключении через конфигуратор с помощью БСП, можно гораздо гибче настраивать. Плюс любая внешняя обработка это для платформы и заказчика потенциально опасный код, особенно если, как в большинстве случаев, отключается безопасный режим.

Я не критикую. Мне правда интересно, вдруг я чего то не вижу не понимаю, и есть какие то плюсы во внешних обработках
12. da_1c 193 13.06.25 21:06 Сейчас в теме
(11) Хороший вопрос. Уточню, что в текущей публикации вообще не затрагиваются изменения в конфигурации основной базы с данными - она может оставаться на поддержке. Расширения по моему мнению сложнее сопровождать, особенно в долгую.
Внешние обработки я использую как микросервисы: они как бы живут отдельно и независимо. Это удобно при распределённой разработке и гибче в доработке.
А про БСП: из-за нестабильности и изменений от версии к версии, давайте лучше не трогать эту тему здесь )))
13. kastielm368 18.06.25 15:53 Сейчас в теме
(12)
Расширения по моему мнению сложнее сопровождать, особенно в долгую.
если их много, то да. А если все или большая часть доработок в одном расширении, то сложностей никаких. Особенно с хранилищем конфигурации.

(12)
Внешние обработки я использую как микросервисы: они как бы живут отдельно и независимо. Это удобно при распределённой разработке и гибче в доработке.
понял вас. У нас с вами видимо сильно разный опыт. На проектах, где я участвовал, внешние обработки создавали только путаницу.

(12)
А про БСП: из-за нестабильности и изменений от версии к версии
не совсем понял о какой нестабильности идет речь. Вся ERP на БСП построена, при возникновении ошибок, их обычно исправляют с релизами. Да и к тому же, вы как бы противопоставляете внешние обработки БСП, но ведь функционал Дополнительных отчетов и обработок входит в состав БСП. А значит нестабильность распространяется и на них.
14. da_1c 193 20.06.25 04:02 Сейчас в теме
(13) Благодарю за вашу точку зрения.
Расширения иногда тянут лишние объекты, которые потом сложно вычищать. Как Вы управляете такими "мусорными" объектами, чтобы поддержка оставалась удобной?
Когда говорил о нестабильности БСП, имел в виду изменения в названиях и сигнатурах методов между версиями, что затрудняет долгосрочную поддержку кода, зависящего от них.
Расширения хороши для точечных или небольших кастомизаций, а внешние обработки - для гибкости и независимости.
15. user1832003 57 26.06.25 07:02 Сейчас в теме
(14) уже год или 2 как расширение видит все объекты в тех же запросах, потом спрашивает добавить ли все в расширение или нет. Нажимаешь нет и никаких проблем.

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

БСП стабильно работает в любой базе при чем с разницей версий, потому что там оставляют совместимость. Тот же ДлительныеОперации.ВыполнитьВФоне() помечена как устаревшая уже кучу лет, но все еще остается в коде. Другое дело что ты под бсп подразумеваешь все что типовое, а это не так. Типо ОбщегоНазначенияУТ для тебя это бсп, а это даже в теории не так
16. kastielm368 28.06.25 12:43 Сейчас в теме
(14)
Как Вы управляете такими "мусорными" объектами, чтобы поддержка оставалась удобной?
В регламенте разработки прописано и на код ревью проверяется. Каждый разраб при захвате корня и добавлении в расширение новых объектов, должен оставить в расширении только используемые объекты. Разный мусор вроде стилей и перечислений должен удалять. Так расширение поддерживается в чистом состоянии. Особенно если еще соблюдать условия по расширению типовых методов, например, использовать подписки на события, директивы После и Перед, добавлять вызовы только в общих модулях локализации и тд.

(14)
Когда говорил о нестабильности БСП, имел в виду изменения в названиях и сигнатурах методов между версиями, что затрудняет долгосрочную поддержку кода, зависящего от них.
Это неизбежно всегда. И с внешними обработками также. Если только они не используют исключительно методы платформы. При любом обновлении релиза идет проверка на работоспособность. И в этот момент и исправляются все изменившиеся сигнатуры методов и имена объектов. Не понимаю, как опытному разработчику это может доставлять проблемы.

(14)
Расширения хороши для точечных или небольших кастомизаций
В целом согласен. Но они также вполне подходят и для больших доработок. Только желательно не хранить важных данные в объектах расширения.
Оставьте свое сообщение