Как выполнить пакетное обновление нетиповой конфигурации 1С?

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

Подход 1: Подготовка эталонного файла конфигурации и загрузка через LoadCfg

Самый распространенный и надежный способ обновления однотипных нетиповых баз заключается в предварительной подготовке эталонного файла конфигурации (.cf) на тестовом контуре (копии рабочей базы) с последующей пакетной загрузкой в целевые базы.

Проанализируем последовательность действий для этого сценария:

1. Создаем копию одной из рабочих баз группы на тестовом сервере.
2. В интерактивном режиме выполняем стандартное обновление конфигурации поставщика (через файл .cfu или .cf нового релиза).
3. Выполняем трехстороннее сравнение и объединение, аккуратно перенося все доработки и разрешая возникшие конфликты в модулях.
4. Применяем изменения к базе данных, выполняем проверку работоспособности и отладку.
5. Выгружаем получившуюся конфигурацию в единый файл через меню Конфигурация - Сохранить конфигурацию в файл (получаем эталонный update.cf).

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

rem 1. Создание резервной копии информационной базы
"C:\Program Files\1cv8\current\bin\1cv8.exe" DESIGNER /IBConnectionString "Srvr=Server1C;Ref=Base1;" /DumpIB "C:\Backups\Base1.dt"

rem 2. Загрузка подготовленной конфигурации
"C:\Program Files\1cv8\current\bin\1cv8.exe" DESIGNER /IBConnectionString "Srvr=Server1C;Ref=Base1;" /LoadCfg "C:\Updates\update.cf"

rem 3. Применение изменений к базе данных
"C:\Program Files\1cv8\current\bin\1cv8.exe" DESIGNER /IBConnectionString "Srvr=Server1C;Ref=Base1;" /UpdateDBCfg

Такой подход полностью исключает интерактивные вопросы Конфигуратора во время ночного или регламентного обновления боевых баз.

Подход 2: Использование ключа UpdateCfg с файлом настроек объединения

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

Рассмотрим синтаксис команды пакетного обновления с объединением:

"C:\Program Files\1cv8\current\bin\1cv8.exe" DESIGNER /IBConnectionString "Srvr=Server1C;Ref=Base1;" /UpdateCfg "C:\Updates\1cv8.cfu" -Settings "C:\Updates\settings.xml" -force /UpdateDBCfg

Разберем параметры этой команды подробнее:

1. -Settings — путь к файлу настроек объединения. Данный файл формируется заранее: в интерактивном окне объединения конфигураций настраиваются правила для каждого объекта (взять из файла поставщика, оставить из конфигурации или объединить с приоритетом), после чего настройки сохраняются через меню окна объединения.
2. -force — ключ принудительного продолжения, который подавляет модальные диалоги при обнаружении дважды измененных свойств объектов.
3. -DumpListOfTwiceChangedProperties — дополнительный параметр, позволяющий выгрузить список дважды измененных свойств в отчет для последующего ручного контроля разработчиком.
4. -IncludeObjectsByUnresolvedRefs или -ClearUnresolvedRefs — параметры, определяющие поведение системы при обнаружении ссылок на объекты, исключенные из объединения.

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

Опасность несовпадения внутренних идентификаторов (UUID) метаданных

При использовании команды /LoadCfg критически важно помнить о проблеме идентификаторов объектов. В платформе 1С соответствие метаданных определяется не по имени объекта (например, справочника или реквизита), а по его внутреннему уникальному идентификатору (UUID).

Выясним причину возникновения проблемы: если одинаковые доработки (например, новый реквизит НомерДоговора) создавались программистами вручную в разных базах с одинаковым именем, платформа сгенерировала для них разные UUID. Если в такую базу пакетно загрузить .cf через команду /LoadCfg, платформа посчитает существующий реквизит удаленным, а реквизит из файла — новым. В процессе реструктуризации на этапе /UpdateDBCfg колонка таблицы с данными будет безвозвратно удалена, и создана новая пустая колонка.

Как решить проблему расхождения идентификаторов:

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

Альтернативные и современные архитектурные решения

Для полного исключения рутины при обновлении большого парка измененных баз рекомендуется рассмотреть современные практики разработки на платформе 1С:

1. Перенос доработок в расширения конфигурации (.cfe): Это наиболее эффективная стратегия. Если вынести весь измененный программный код, новые формы и дополнительные реквизиты в механизм расширений, основную конфигурацию можно вернуть на типовую замковую поддержку поставщика. В этом случае базы обновляются стандартным ключом /UpdateCfg без риска затереть доработки и без проблем с UUID.
2. Использование хранилища конфигурации: Каждая рабочая база может быть подключена к выделенному регламентному хранилищу. В хранилище помещается проверенный и объединенный релиз, а на боевых базах выполняется автоматическое обновление из хранилища через пакетную команду /ConfigurationRepositoryUpdateCfg с последующим /UpdateDBCfg.
3. Выгрузка конфигурации в файлы и трехстороннее слияние: Использование команд /DumpConfigToFiles и /LoadConfigFromFiles позволяет вести версионирование в системе контроля версий (Git) и выполнять объединение веток исходных текстов автоматизированными инструментами до сборки финального файла поставки.