Автоматизация сборки расширений 1С: Бесшовный переход от 1C:EDT к Конфигуратору
Построение сквозного CI/CD пайплайна: трансляция текстовых исходников EDT в бинарные контейнеры .cfe без ручного участия разработчика и открытия Конфигуратора.
Архитектурный анализ утилит ring и ibcmd, трансформация процессов разработки и кроссплатформенный сборочный скилл на Node.js
Введение: Прагматичный подход к выбору инструментов
В среде 1С-разработчиков периодически возникают споры о том, что лучше: классический Конфигуратор или современная среда 1C:Enterprise Development Tools (EDT). На самом деле это не конкурирующие «прошлое и будущее», а два инструмента, созданные под принципиально разные задачи.
- Классический Конфигуратор незаменим для оперативного решения точечных задач. Если нужно зайти в базу, быстро найти ошибку, сделать мелкий фикс прямо «на месте» и мгновенно запустить отладку - Конфигуратор выигрывает за счет скорости. Он работает с базой метаданных напрямую, не требуя предварительного импорта исходников и тотальной индексации.
- 1C:EDT (тяжелая IDE на базе Eclipse/Java) создавалась для сложной командной разработки. На нее переходят ради избавления от монопольного захвата объектов в Хранилище, ведения параллельной работы в полноценном Git (с ветвлением, пул-реквестами и код-ревью), статического анализа кода, авторефакторинга и интеграции современных ИИ-ассистентов.
Однако при совмещении этих инструментов возникает технический разрыв: разработчики пишут код в EDT в виде текстовых исходников (структурированных XML-файлов и модулей в формате Eclipse), а рантайм платформы 1С по-прежнему выполняет только бинарные упакованные контейнеры конфигураций (.cf) и расширений (.cfe).
Эта статья посвящена тому, как настроить бесшовный автоматический мост между исходным кодом в EDT и исполняемым файлом Конфигуратора в рамках CI/CD пайплайна, чтобы разработчикам и администраторам вообще не приходилось открывать Конфигуратор вручную ради рутинных операций сборки и упаковки.
Под капотом: Архитектурные ограничения утилит ring и ibcmd
При проектировании сборочных конвейеров у инженеров часто возникает вопрос: «Зачем привлекать классический Конфигуратор или создавать временные базы данных, если у нас есть консольная утилита ring или ibcmd?»
Ответ кроется в особенностях внутренней архитектуры инструментов автоматизации фирмы «1С».
1. Утилита ring как диспетчер трансляции
Сама по себе утилита ring является кроссплатформенной Java-оболочкой и менеджером плагинов. Она не содержит собственного компилятора метаданных 1С. За работу с проектами отвечает устанавливаемый модуль edt (EDT CLI).
Когда мы выполняем экспорт проекта:
Происходит только трансляция схем метаданных. Модуль EDT CLI берет структуру файлов проекта (ориентированную на Eclipse и Git) и преобразует её в классическую структуру XML-файлов Конфигуратора. На выходе мы получаем каталог с тысячами XML-файлов и модулей BSL, но не бинарный файл .cfe или .cf. Сама EDT физически не содержит компилятора, способного упаковать эти исходники в бинарный контейнер.
2. Ограничения утилиты ibcmd
Для работы с конфигурациями в автономном («offline») режиме поставляется утилита ibcmd (компонент автономного сервера). С её помощью можно импортировать файлы конфигурации:
Однако ibcmd не является изолированным консольным компилятором. Для выполнения этой команды ей в обязательном порядке требуется инициализировать СУБД (указать параметр --data или путь к файловой базе данных). Под капотом утилита разворачивает таблицы файловой СУБД на диске, выполняет туда загрузку метаданных, сериализует их и только после этого позволяет выгрузить бинарный файл.
Архитектурный вывод:
В экосистеме 1С на данный момент не существует автономного утилитарного сборщика, способного упаковать исходные файлы в бинарный контейнер без физического развертывания СУБД (пусть даже временной файловой базы данных на диске) и обращения к механизмам платформы «1С:Предприятие» (1cv8).
Именно поэтому автоматизированный конвейер должен брать эту двухэтапную рутину на себя:
- Вызвать
ringдля трансляции метаданных проекта EDT в формат XML Конфигуратора. - Инициализировать временную информационную базу средствами платформы.
- Выполнить пакетный импорт XML-файлов во временную базу и выгрузить готовый бинарный файл (
.cf/.cfe).
Жизненный цикл расширения в разрезе трех ролей
Давайте посмотрим, как автоматизация этого процесса влияет на повседневную работу ключевых участников ИТ-команды.
1. Программист 1С: Исключение рутины
- Без автоматизации: Для передачи доработок на тестирование программисту приходится прерывать работу в EDT, запускать экспорт в XML, открывать Конфигуратор, создавать локальную базу, загружать файлы и выгружать
.cfe. Этот процесс занимает значительное время на каждую итерацию. Из-за спешки разработчики часто пропускают синтаксический контроль модулей во всех контекстах. - С автоматизацией: Разработчик работает исключительно в EDT. При завершении задачи он выполняет стандартный
git push. Сборочный конвейер сам конвертирует проект, компилирует.cfeи запускает фоновый синтаксический контроль модулей во всех контекстах (сервер, тонкий клиент, веб-клиент), не отвлекая программиста.
2. DevOps-инженер / Системный администратор: Стабильность окружения
- Без автоматизации: Настройка сборки на headless-серверах Linux требует ручного управления виртуальными дисплеями (Xvfb), очистки зависших файлов блокировок (
.1cLck) после аварийных завершений процессов и обработки нетипичных кодировок логов 1С (UTF-16LE / CP1251). - С автоматизацией: Инструмент сборки полностью инкапсулирует логику определения версий EDT и платформы. Пайплайн автоматически изолирует рабочие сессии (используя уникальный
RUN_ID), нормализует логи сборки в UTF-8, корректно гасит процессы Xvfb и транслирует внутренние коды возврата платформы 1С в стандартные системные сообщения.
3. Архитектор ИТ-систем: Контроль версий как единственный источник правды
- Без автоматизации: Повышается риск несанкционированного изменения кода, когда бинарные файлы
.cfeсобираются разработчиками локально и могут содержать незафиксированные в Git изменения или не пройти финальное синтаксическое тестирование в целевом окружении. - С автоматизацией: Архитектор внедряет правило: любые изменения попадают в тестовые и продуктивные контуры только через автоматическую сборку на сервере CI/CD. Пайплайн гарантирует, что работающий в СУБД бинарный код на 100% эквивалентен исходному коду, зафиксированному в репозитории Git.
Инструмент автоматизации: Скилл edt-to-configurator.js
Для решения этой задачи разработан легковесный автономный инструмент edt-to-configurator.js, написанный на Node.js без внешних зависимостей.
Этот файл спроектирован по спецификации Agent Skills (стандарт agentskills.io) и может использоваться как:
- Самостоятельная CLI-утилита в терминале или CI/CD скриптах сборки.
- Расширение (Skill) для ИИ-агентов (например, GitHub Copilot CLI, Claude Code, Cursor, Codex), позволяющее ИИ-помощникам самостоятельно компилировать проекты EDT по текстовому запросу пользователя благодаря декларативному блоку метаданных.
Ключевые возможности:
- Автоопределение окружения: Автоматически ищет установленные версии платформы «1С:Предприятие» (в Windows/Linux) и установленные версии EDT в реестре утилиты
ring. - Парсинг проекта: Автоматически извлекает имя проекта из служебного файла
.projectвнутри целевого каталога. - Безопасность и очистка: Самостоятельно разворачивает временную файловую базу в каталоге ОС, выполняет импорт и после успешного (или аварийного) завершения полностью очищает дисковое пространство.
- Кроссплатформенность: Построен на стандартных Node.js API (fs, path, child_process, os), что гарантирует работу как в Windows, так и на Linux.
Инструкция по использованию
CLI-команда конвертации
Скрипт принимает параметры через стандартные аргументы командной строки:
Доступные аргументы команды convert:
--projectDir(обязательный) - путь к каталогу проекта EDT (где лежат.projectи папкаsrc).--output(обязательный) - путь для сохранения результата (файл.cfeили каталог для XML-выгрузки при ключе--xmlOnly).--edtVersion(опционально) - конкретная версия EDT (например,edt@2025.2.0), если их несколько. По умолчанию автоопределяется.--platformPath(опционально) - вручную указанный путь к исполняемому файлу платформы 1С (1cv8).--extensionName(опционально) - имя расширения в базе 1С. По умолчанию считывается из файла.project.--xmlOnly(опционально, логический) - выгрузить только в формате XML-исходников Конфигуратора без последующей сборки бинарного.cfe.
Пример интеграции в CI/CD пайплайны
Вариант 1: GitLab CI (.gitlab-ci.yml)
Благодаря Node.js и кроссплатформенности, шаг сборки в GitLab Runner на Linux выглядит максимально просто:
Вариант 2: GitHub Actions (.github/workflows/build.yml)
Аналогичный шаг сборки для GitHub раннеров:
Заключение
Автоматизация трансляции и сборки из EDT в формат Конфигуратора - это прагматичное преодоление архитектурных ограничений платформы. Наличие утилиты ring решает задачу трансляции метаданных, но для финальной сборки нам всё еще нужно ядро СУБД 1С.
Перенос этой рутины в автоматический CI/CD-конвейер с помощью скилла edt-to-configurator.js позволяет разработчикам сосредоточиться на написании кода в современной IDE, администраторам - получить стабильные headless-сборки на серверах, а бизнесу - гарантировать надежность работающих систем.
Проверено на следующих конфигурациях и релизах:
- Управление торговлей, редакция 11, релизы 11.5.27.50
Вступайте в нашу телеграмм-группу Инфостарт