CI/CD для 1С через Jenkins и Git за 6 шагов

📅 Опубликовано 13 августа 2026 г.

Коротко: CI/CD для 1С — это связка Git, Jenkins и консольного запуска платформы, которая сама собирает файл cf из исходников, прогоняет автотесты и выкладывает обновление на тестовый контур. Базовая настройка укладывается в 6 шагов и 3–5 рабочих дней. По опыту проектных команд, цикл выпуска релиза сокращается с 3–6 часов ручных операций до 20–40 минут, а доля релизов с забытыми объектами метаданных падает почти до нуля.

Что такое CI/CD для 1С и что он реально даёт?

CI/CD (Continuous Integration / Continuous Delivery) — это конвейер, который забирает изменения разработчиков из системы контроля версий, автоматически собирает из них поставку и проверяет её тестами. Для 1С конвейер строится вокруг трёх элементов: Git хранит исходники конфигурации в виде XML-файлов, Jenkins управляет очередью заданий и запускает шаги, а платформа 1С:Предприятие в пакетном режиме выполняет саму работу — загрузку, сборку, обновление баз.

Главное заблуждение руководителей — что CI/CD нужен только «большим командам с десятью программистами». На практике конвейер окупается уже при двух-трёх разработчиках и одной активно дорабатываемой базе, потому что закрывает не проблему масштаба, а проблему повторяемости: каждый релиз собирается одинаково, из одних и тех же исходников, без зависимости от того, кто именно сегодня на смене.

Минимальный контур: один сервер сборки (4 vCPU, 8–16 ГБ RAM, SSD от 200 ГБ), лицензия платформы для агента, Git-репозиторий и Jenkins LTS.
Обязательное условие: конфигурация должна выгружаться в файлы XML — без этого версионирование и сравнение изменений теряют смысл.
Сборка cf для типовой конфигурации на 12–20 тысяч объектов метаданных занимает 8–25 минут, дымовые автотесты — ещё 20–40 минут.
Выкладка на рабочую базу всегда остаётся полуавтоматической: конвейер готовит всё, но финальную кнопку нажимает человек.
Срок внедрения базового пайплайна — 3–5 рабочих дней, полноценного с тестами и несколькими контурами — 3–6 недель.

Чем автоматический релиз отличается от ручного?

Операция	Ручной процесс	CI/CD-конвейер
Сборка поставки cf	30–60 мин, вручную в конфигураторе	8–25 мин, по коммиту
Проверка синтаксиса и ссылок	Выборочно, «на глаз»	Каждая сборка, автоматически
Прогон тестов	Чаще всего не выполняется	20–40 мин, дымовой набор
Обновление тестовой базы	20–40 мин + участие человека	5–15 мин, без участия
Откат неудачного релиза	Поиск последней копии, 1–3 часа	Прошлый артефакт cf, 10–20 мин
Риск «забыли объект»	Высокий	Практически исключён

Шаг 1. Как подготовить инфраструктуру и лицензии?

Начинать нужно не с Jenkins, а с инвентаризации. Отдельный сервер сборки обязателен: запускать конвейер на машине разработчика или на продуктивном сервере 1С нельзя — сборка потребляет диск и процессор рывками и может конфликтовать с регламентными заданиями.

Минимальная спецификация для одной конфигурации среднего размера — 4 vCPU, 8 ГБ RAM, 200 ГБ SSD. Если планируется параллельная сборка нескольких конфигураций или восстановление баз из копий, закладывайте 8 vCPU, 32 ГБ RAM и 500 ГБ–1 ТБ диска: выгрузка конфигурации в XML для крупной ERP-базы может занимать десятки гигабайт вместе с временными файлами.

Какие лицензии и учётные записи понадобятся?

Клиентская лицензия 1С для агента сборки — конвейер запускает конфигуратор в пакетном режиме, и это полноценный сеанс.
Серверная лицензия, если тестовые базы будут развёрнуты в клиент-серверном варианте.
Служебная учётная запись в базе с правами администратора и включённой аутентификацией 1С — доменная аутентификация в пакетном режиме работает нестабильно.
Техническая учётная запись в Git с доступом на чтение и запись, желательно по SSH-ключу, а не по паролю.
Установленные платформы всех версий, с которыми работают базы: конвейер должен уметь собирать под 8.3.21, 8.3.24 и любую другую версию, а не под одну «последнюю».

Отдельно зафиксируйте политику паролей: если пароль служебной учётной записи меняется по расписанию безопасности, пайплайн упадёт в ближайшую ночь. Такие пароли выносят в хранилище учётных данных Jenkins (Credentials) и обновляют централизованно.

Шаг 2. Как выгрузить конфигурацию 1С в Git?

Это самый содержательный шаг, потому что здесь принимается решение о модели работы команды. Есть два рабочих варианта.

Вариант A — «Хранилище как источник». Команда продолжает работать через хранилище конфигурации, а отдельное задание Jenkins раз в 10–15 минут выгружает новые версии хранилища в файлы XML и коммитит их в Git с сохранением автора и комментария. Плюс — ничего не меняется в привычках разработчиков. Минус — Git используется в основном как журнал и база для сборки, полноценных веток и ревью не будет.

Вариант B — «Git как источник». Разработчики выгружают свои доработки в файлы, работают в ветках, делают запросы на слияние, а конфигурация собирается из веток. Модель мощнее, но требует дисциплины и обучения команды. Подробный разбор обоих подходов, включая структуру репозитория и правила именования веток, мы делали в материале про хранение конфигурации 1С в Git и построение CI/CD — если команда ещё не выбрала модель, начните с него.

Что положить в репозиторий, а что — нет?

В репозиторий кладут: выгрузку конфигурации в XML, выгрузку расширений, файлы внешних отчётов и обработок в исходниках, скрипты пайплайна, сценарии автотестов и файл описания релиза. Не кладут: собранные cf и cfu, дампы баз, архивы, временные каталоги конфигуратора и любые файлы с реальными персональными данными. Для этого сразу заводится файл исключений .gitignore.

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

Шаг 3. Как настроить Jenkins и агента сборки?

Устанавливайте LTS-версию Jenkins — она получает исправления безопасности и совместима с большинством плагинов. Сразу после установки выполните четыре обязательных действия.

Включите авторизацию. Раздел «Настроить Jenkins» → «Безопасность»: матрица прав, отдельные роли для разработчиков (запуск и просмотр) и администраторов (изменение заданий).
Установите плагины: Git, Pipeline, Credentials Binding, Workspace Cleanup, а также плагины публикации отчётов о тестах (формат JUnit) и уведомлений в корпоративный мессенджер или почту.
Заведите узел-агент. Даже если Jenkins и платформа стоят на одной машине, вынесите сборку на отдельный узел с меткой (label) вида 1c-build. Это позволит позже добавить второй сервер без переписывания заданий.
Добавьте учётные данные в раздел Credentials: ключ доступа к Git, логин и пароль администратора баз, пароль пользователя хранилища конфигурации. В скриптах должны фигурировать только идентификаторы учётных данных, никогда — открытые пароли.

Задание в интерфейсе или скриптом?

Для первого пайплайна допустимо собрать задание типа Freestyle через веб-интерфейс: это быстрее и нагляднее. Но уже на втором конвейере переходите к описанию pipeline в файле, который лежит в самом репозитории. Тогда изменение процесса сборки проходит те же ревью, что и изменение кода, а восстановление Jenkins после сбоя сводится к переустановке и подключению репозитория, а не к ручному воспроизведению трёх десятков галочек.

Шаг 4. Как настроить автосборку cf из исходников?

Логика этапа сборки всегда одна и та же, независимо от инструментов-обёрток: создать пустую файловую базу, загрузить в неё конфигурацию из XML, выгрузить результат в cf и сохранить как артефакт задания.

Все действия выполняются через пакетный запуск платформы. Единственный фрагмент командной строки, без которого объяснить этап невозможно, выглядит так:

"C:\Program Files\1cv8\8.3.24.1234\bin\1cv8.exe" DESIGNER /F "D:\build\tmpbase" /N Администратор /P *** /LoadConfigFromFiles "D:\build\src\cf" /UpdateDBCfg -Server /Out "D:\build\logs\load.log"

Далее той же командой с ключом выгрузки формируется файл cf. Разберём, что должно происходить вокруг этого вызова.

Проверка кода возврата. Платформа возвращает ненулевой код при ошибке, но иногда завершается «успешно» с ошибками в логе. Правило: считать сборку неудачной, если код возврата не равен нулю или в файле лога встретились строки со словами «Ошибка» и «не удалось».
Таймаут. Зависший конфигуратор — самая частая причина «висящих» заданий. Ставьте ограничение в 60–90 минут и принудительно завершайте процесс.
Очистка рабочего каталога до и после сборки: остатки временной базы от прошлого прогона искажают результат.
Версионирование артефакта. Имя файла формируйте как Имя_Конфигурации_1.2.3.45_build127.cf, где последний блок — номер сборки Jenkins. Это единственный надёжный способ понять, какой именно cf стоит в базе.
Срок хранения: держите последние 20–30 сборок и все релизные — это десятки гигабайт, но именно они обеспечивают быстрый откат.

Отдельно настройте сборку файла обновления cfu для тиражных решений и сборку расширений: расширения собираются в cfe той же командой и должны проверяться на совместимость с текущей версией основной конфигурации — иначе после обновления они молча отключатся.

Шаг 5. Как подключить автотесты и что тестировать в первую очередь?

Ошибка большинства первых внедрений — попытка сразу покрыть тестами бизнес-логику. Это долго, дорого и почти всегда заканчивается брошенными сценариями. Начинать нужно с дымового набора (smoke-тестов), который отвечает на один вопрос: «конфигурация вообще запускается и открывается?».

Из чего состоит минимальный набор тестов?

Синтаксический контроль. Запускается прямо на этапе сборки, ловит ошибки компиляции модулей. Занимает 3–10 минут.
Открытие всех форм. Дымовой сценарий последовательно открывает списки, формы объектов и отчёты. Именно он ловит 60–70% регресса после обновления типовой конфигурации.
Проведение ключевых документов. 10–15 сценариев: реализация, поступление, оплата, начисление зарплаты — то, что останавливает работу компании при поломке.
Проверка обменов и интеграций. Отправка тестового документа во внешнюю систему, проверка регламентных заданий обмена.
Проверка отчётности. Формирование двух-трёх ключевых регламентированных отчётов с эталонными данными.

Инструменты выбирают по задаче: сценарные тесты пользовательского интерфейса пишут в Vanessa Automation на понятном языке Gherkin — сценарий читается бухгалтером и может им же проверяться; модульные тесты серверной логики удобнее делать через фреймворки юнит-тестирования. Результаты обязательно выгружайте в формате JUnit — Jenkins построит по ним график и покажет, какие тесты «мигают».

Тестовые данные — отдельная тема. Использовать копию рабочей базы без обезличивания нельзя: это персональные данные и коммерческая тайна на сервере сборки. Правильный путь — эталонная база с сгенерированными данными либо копия с обязательным этапом обезличивания (замена ФИО, телефонов, реквизитов контрагентов, отключение почты и обменов). Этап обезличивания встраивается в тот же пайплайн и выполняется автоматически при каждом восстановлении копии.

Правило приёмки: если дымовой набор красный — релиз не выкладывается ни при каких обстоятельствах. Как только команда позволяет себе первое исключение «ну там тест просто старый», тесты умирают за два-три месяца.

Шаг 6. Как автоматизировать выкладку обновлений на базы?

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

Что должен делать пайплайн выкладки?

Проверить наличие резервной копии и её актуальность. Нет свежей копии — задание останавливается с ошибкой, а не «на всякий случай продолжает».
Завершить сеансы пользователей и заблокировать вход через настройки блокировки в кластере или консоль администрирования.
Загрузить cf и выполнить обновление конфигурации базы данных в пакетном режиме.
Запустить обработчики обновления и дождаться их завершения — на крупных базах это самая длинная операция, от 10 минут до нескольких часов.
Снять блокировку и выполнить короткий проверочный сценарий: вход пользователя, открытие двух-трёх ключевых форм.
Отправить уведомление с номером сборки, версией конфигурации, длительностью и ссылкой на лог.

Ключевое требование к пункту 3 — заранее измеренное окно обновления. Именно поэтому существует предпродуктивный контур: он показывает, сколько на самом деле займёт обновление на объёме реальных данных. Для тяжёлых систем этот замер критичен; аналогичный подход мы описывали в разборе подготовки 1С:Документооборот к обновлению, где длительность обработчиков — главный фактор планирования.

План отката прописывается до первого автоматического релиза и должен быть исполним за 20–30 минут: восстановление базы из копии либо загрузка предыдущего артефакта cf. Проверьте откат на тестовом контуре хотя бы один раз — план, который никогда не выполняли, планом не является.

Найдите специалиста для решения этой задачи на koderion.ru