Автоматизация сборки расширений 1С: Бесшовный переход от 1C:EDT к Конфигуратору

Введение: Прагматичный подход к выбору инструментов

В среде 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С: Исключение рутины

• Без автоматизации: Для передачи доработок на тестирование программисту приходится прерывать работу в 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) и может использоваться как:

1. Самостоятельная CLI-утилита в терминале или CI/CD скриптах сборки.
2. Расширение (Skill) для ИИ-агентов (например, GitHub Copilot CLI, Claude Code, Cursor, Codex), позволяющее ИИ-помощникам самостоятельно компилировать проекты EDT по текстовому запросу пользователя благодаря декларативному блоку метаданных.

Инструкция по использованию

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-сборки на серверах, а бизнесу - гарантировать надежность работающих систем.