В процессе командной разработки на платформе «1С:Предприятие» часто возникает задача разграничения контуров. Типичный сценарий: разработчик завершает задачу в тестовом контуре, тестировщик проверяет функционал, и после успешной проверки код должен попадать в рабочую (продакшн) базу. Возникает логичный вопрос: можно ли подключить одну и ту же информационную базу сразу к двум хранилищам — тестовому и продакшн? В этой статье мы подробно разберем технические ограничения платформы и рассмотрим лучшие практические схемы организации многоконтурной разработки.
Давайте проанализируем, как устроена связь между информационной базой и хранилищем конфигурации 1С. Платформа жестко связывает конкретную базу с одним хранилищем. Информация об этом подключении записывается в служебных таблицах самой информационной базы. Там фиксируются:
Если попытаться поочередно отключать базу от одного хранилища и подключать к другому, мы неизбежно столкнемся со следующими критическими проблемами:
ERP Управление предприятием, Комплексная автоматизация или Управление торговлей, этот процесс может занимать от 30 минут до нескольких часов, что сводит на нет всю эффективность разработки.Поэтому идея прямого переподключения одной базы к разным хранилищам является нежизнеспособной. Тем не менее, настроить надежный процесс переноса изменений между контурами разработки, тестирования и продакшена вполне реально. Рассмотрим наиболее эффективные методы.
Этот подход не требует сторонних инструментов и базируется на стандартных возможностях Конфигуратора 1С. Мы разделяем процесс разработки на три независимых контура, у каждого из которых есть своя пара «База + Хранилище»:
Рассмотрим по шагам процесс переноса изменений по этой схеме:
.cf) из базы Dev..cf. Важно захватить необходимые объекты в Хранилище Test перед объединением, а после успешного объединения — поместить их обратно в Хранилище Test.Главный плюс этого метода — полный контроль над тем, какие именно объекты переносятся на продакшн. Главный минус — высокие трудозатраты на ручное сравнение и объединение конфигураций.
Чтобы избавить разработчиков от рутины ручного сравнения и объединения, этот процесс можно автоматизировать. Конфигуратор 1С поддерживает запуск из командной строки с параметрами. Мы можем написать скрипт на языке OneScript или использовать обычный командный файл Windows (bat/cmd), который будет выполнять перенос автоматически.
Давайте разберем пример сценария автоматического обновления тестового хранилища из конфигурации разработки. Нам понадобятся следующие параметры командной строки:
Шаг 1. Выгрузка конфигурации из базы разработки в файл dev_dump.cf:
"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" DESIGNER /F "C:\DB\DevBase" /N "Admin" /P "Pass" /DumpCfg "C:\CF\dev_dump.cf"
Шаг 2. Подключение к тестовой базе, автоматический захват измененных объектов в тестовом хранилище, сравнение и объединение с файлом dev_dump.cf, а также последующее обновление конфигурации базы данных:
"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" DESIGNER /F "C:\DB\TestBase" /N "Admin" /P "Pass" /ConfigurationRepositoryF "C:\Repositories\TestRepo" /ConfigurationRepositoryN "RepoAdmin" /ConfigurationRepositoryP "RepoPass" /MergeCfg "C:\CF\dev_dump.cf" /UpdateDBCfg
Использование подобных скриптов позволяет значительно сократить время на рутинные операции. Для более продвинутой автоматизации можно использовать готовые утилиты, такие как «Менеджер переноса изменений между хранилищами», доступные на профильных сообществах разработчиков 1С.
Этот метод часто применяется в крупных проектах и корпоративном секторе. Вместо прямого переноса объектов метаданных между хранилищами используется механизм создания файлов поставки и обновлений (файлы .cfu или готовые дистрибутивы обновлений).
Проанализируем этот сценарий подробнее:
Такой подход гарантирует целостность базы данных продакшена, исключает случайное затирание объектов метаданных и позволяет вести структурированную историю версий продукта.
Если ваша команда разработки постоянно страдает от монопольных блокировок объектов в хранилище (например, когда несколько разработчиков одновременно ждут освобождения общих ролей, общих модулей или планов видов характеристик), классическое хранилище 1С становится узким горлышком. В этом случае единственным надежным системным решением является переход на распределенную систему контроля версий Git и использование среды разработки 1С:EDT (Enterprise Development Tools).
Переход на Git полностью решает озвученные проблемы за счет следующих механизмов:
feature/task-452). В этой ветке программист может редактировать любые общие модули, формы и роли. Это никому не мешает.Vanessa Automation или xUnitFor1C) при каждом помещении кода в репозиторий. Если тесты пройдены успешно, код автоматически собирается в файл конфигурации и доставляется на продакшн контур.Если ваша команда пока не готова полностью отказаться от привычного Конфигуратора 1С и перейти на требовательную к ресурсам компьютера среду EDT, можно использовать гибридный подход с утилитой gitsync.
Схема работы выглядит так:
gitsync непрерывно отслеживает появление новых версий в хранилище 1С.Это позволяет получить полноценную историю изменений в Git, проводить код-ревью в веб-интерфейсе (например, в GitHub или GitLab) и запускать автоматические тесты, сохраняя привычный процесс работы в Конфигураторе.
Подводя итог, выделим ключевые тезисы для выбора оптимальной стратегии организации разработки:
.cf.