1С без конфигуратора: как собрать и выкатить расширение из командной строки

Разработку расширения 1С можно вести полностью без конфигуратора: конфигурация хранится как XML-файлы в git, правки вносят в 1С:EDT, а сборку, тестовую базу и обновление рабочих баз выполняют команды designer.exe и ibcmd из командной строки — тонкий клиент открывают только в аварийном случае.

где конфигуратор ломает релиз расширения

В компании на 1С:Управление торговлей два программиста дорабатывали одно расширение — обмен заказами с маркетплейсом. Пятница, конец месяца, оба открыли конфигуратор одновременно, чтобы успеть до вечера. Один сохранил правку в общем модуле, второй — в форме документа; конфигуратор принял оба сохранения, но при следующем открытии часть кода потерялась, а база на время ушла в монопольный режим реиндексации.

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

что значит «без конфигуратора» на практике

«Без конфигуратора» не значит «без 1С:EDT» и не значит «без правил». Значит — конфигурация лежит не внутри базы данных, а как обычные файлы: каждый объект метаданных, общий модуль, форма — отдельный файл в репозитории git. Такой расширенный формат файлов конфигурации EDT использует для хранения проекта расширения на диске.

Правки вносят в EDT — среде разработки на Eclipse с построчным diff и подсветкой конфликтов до слияния, а не после. Обмен с самой базой 1С — тестовой или рабочей — идёт не через клик «Обновить конфигурацию базы данных», а через вызов утилит: designer.exe с ключами /DumpConfigToFiles и /LoadConfigFromFiles выгружает и загружает конфигурацию без графического окна, а ключ -Extension с именем расширения указывает, что операция идёт с конкретной доработкой, а не со всей конфигурацией сразу. ibcmd берёт на себя обслуживание самой информационной базы: создание, резервное копирование, часть операций с конфигурацией — тоже без интерфейса. Любой из этих вызовов встраивается в bat- или sh-сценарий и запускается по коммиту в git, без участия человека за экраном.

EDT распространяется бесплатно для конфигураций на управляемых формах, поэтому конвейер не добавляет лицензионных затрат сверх того, что уже нужно для разработки — платят за время инженера и за сервер под сборку, а не за инструмент.

путь расширения от коммита до продуктивной базы

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

1. экспорт конфигурации в файлы

Первый прогон — разовый. Действующую базу выгружают в файлы командой designer.exe /DumpConfigToFiles, а расширение — тем же ключом с добавлением -Extension и именем расширения. Файлы попадают под git, и с этого момента история правок расширения читается по коммитам, а не восстанавливается по памяти программиста.

2. правка в EDT и коммит

Разработчик открывает проект расширения в EDT, меняет модуль или форму и видит построчный diff перед коммитом. Конфликт с коллегой EDT покажет на слиянии веток — как в любом языке программирования, а не после того, как оба уже сохранили изменения в одну базу.

3. сборка и тесты на выделенной базе

Сборочный сервер подхватывает коммит, поднимает тестовую информационную базу — свою для каждого прогона — и загружает в неё расширение через /LoadConfigFromFiles -Extension. На этой базе гоняют автотесты, а если расширение трогает форму или отчёт, которым пользуются активно, дополнительно прогоняют тест Гилёва — он ловит проседание производительности раньше, чем это заметят пользователи рабочей базы.

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

4. обновление через ibcmd и designer.exe

После зелёных тестов конфигурацию расширения обновляют в рабочей базе: designer.exe с ключом /UpdateDBCfg -Extension применяет изменения к структуре, а ibcmd закрывает операции уровня инфобазы — резервную копию перед обновлением, проверку версии платформы, откат при ошибке.

Если обновление структуры прошло, но расширение всё равно работает не так, откат — это восстановление резервной копии, снятой перед /UpdateDBCfg, а не поиск, какую строчку кода откатить руками. Разница с конфигуратором именно в этом: там резервную копию снимают, только если про неё вспомнили заранее.

5. раскатка на рабочие базы

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

конфигуратор, ручной EDT и headless-конвейер: что выбрать

какая дисциплина нужна команде, помимо скриптов

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

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

где headless-конвейер спотыкается

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

Версия EDT должна соответствовать версии платформы, на которой работает база, — расхождение на одну-две сборки конвертер решает молча не всегда, и в логе сборки вместо понятной ошибки можно получить пустой список объектов. Первую настройку конвейера поэтому делают на той же версии платформы, что стоит на рабочих базах, а не на последней доступной.

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

что делаем мы и во что это обходится

Мы переносим доработку 1С в такой конвейер поэтапно: сначала выгружаем текущую конфигурацию и расширения в git и заводим проект в EDT, потом поднимаем сборочный сервер с тестовой базой, в последнюю очередь переключаем обновление рабочих баз на скрипты. Сама доработка 1С — модуля, отчёта, обмена с маркетплейсом — идёт по обычной расценке инженера; настройка и сопровождение конвейера, резервного копирования и обновлений баз — по ставке сопровождения 1С и сисадмина, 3800 руб/час.

Под сборочный сервер и тестовые базы не обязательно покупать железо: внедрение 1С у нас включает вариант с сервером в аренде от 1 100 ₽/мес за пользователя, где конвейер живёт отдельно от рабочей базы и не мешает ей в момент сборки. Для компании из примера выше это развело бы конфликт программистов и закрытие месяца бухгалтерией физически — на двух разных базах вместо одной. Настройка конвейера с нуля — работа на несколько дней инженера, а не месяцы: перенос уже готового расширения в git и первая сборка обычно укладываются в одну итерацию, дальше конвейер обслуживает сам себя.

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

❓ Частые вопросы

Можно ли разрабатывать расширение 1С без покупки 1С:EDT?

Технически да — designer.exe и ibcmd работают из командной строки и без EDT, но тогда правки в код вносят обычным текстовым редактором, теряя построчный diff и подсветку конфликтов. EDT бесплатен для конфигураций на управляемых формах, поэтому экономить на нём в headless-конвейере обычно нет смысла.

Что будет с существующими доработками при переходе на этот подход?

Ничего не переписывают с нуля: текущее расширение один раз выгружают в файлы через designer.exe /DumpConfigToFiles -Extension, заводят проект в EDT и с этого коммита ведут историю в git. Логика работы бухгалтеров и программистов не меняется — меняется только то, как правки попадают в базу.

Нужен ли отдельный сервер под сборку и тесты расширения?

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

Как быстро откатить неудачное обновление расширения?

Скрипт снимает резервную копию базы перед вызовом /UpdateDBCfg, поэтому откат — это восстановление из неё, а не ручной поиск, что сломалось. В конфигураторе без такого шага откат обычно означает пересборку расширения по логам, как в примере с потерянным кодом общего модуля.

Подходит ли headless-конвейер для мелких правок раз в месяц?

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