Как правильно обновить несколько однотипных доработанных баз 1С через хранилище или CF-файл?

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

Архитектурные риски использования хранилища конфигурации для продуктивных баз

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

1. Назначение механизма: Хранилище конфигурации платформы 1С разработано исключительно для коллективной разработки. База хранилища представляет собой файловую структуру (файл 1Cv8ddb.1CD). Одновременное обращение множества рабочих баз по сети создает пиковую нагрузку на файловую систему, что нередко приводит к блокировкам и физическому повреждению самого хранилища.
2. Лавинообразный рост размера: Помещение в хранилище полных релизов конфигурации поставщика стремительно увеличивает его объем, приводя к сильным задержкам при получении данных и деградации производительности.
3. Человеческий фактор: Если рабочая база подключена к хранилищу, специалист с полными правами может случайно захватить объекты прямо из «продакшна» или поместить несогласованную конфигурацию.

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

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

Если 15 баз создавались в разное время из разных шаблонов или обновлялись вручную, внутренние идентификаторы даже одноименных таблиц и реквизитов могут различаться. При полной загрузке конфигурации (или первичном подключении к хранилищу) конфигурация замещается целиком. Если внутренние идентификаторы не совпали, платформа считает, что старые объекты были полностью удалены, а новые — добавлены. В процессе реструктуризации базы на уровне СУБД физическая таблица со старыми учетными данными удаляется и заменяется пустой таблицей с новым UUID. Это приводит к потере документов или справочников (особенно часто возникают коллизии со справочниками вида УдалитьСправочник).

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

Решение 1. Обновление через хранилище конфигурации для баз-клонов

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

1. На отдельной копии базы (базе разработки) выполняем штатное обновление на новый релиз с сохранением всех доработок.
2. Тестируем корректность проведения документов и работу регламентных заданий.
3. Подключаем базу разработки к хранилищу конфигурации, захватываем корень конфигурации и помещаем обновленную конфигурацию нового релиза в хранилище.
4. Поочередно открываем конфигураторы рабочих баз и выполняем команду меню: Конфигурация — Хранилище конфигурации — Получить конфигурацию из хранилища.
5. Применяем изменения к базе данных, согласившись с окном реструктуризации (сочетание клавиш F5 или пункт меню Конфигурация — Обновить конфигурацию базы данных).
6. Запускаем сеанс в режиме «1С:Предприятие» для выполнения регламентных процедур постобновления данных.

Решение 2. Сборка единого CF-файла и пакетное обновление скриптом

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

Проанализируем правильную последовательность действий:

1. Берем тестовую копию одной из баз и последовательно накатываем на нее требуемые релизы обновления поставщика с переносом кастомных изменений. Если релизов несколько, накатывать их необходимо последовательно, чтобы не пропустить логику обработчиков переноса данных БСП (например, когда реквизит в одном релизе переносится в новый и переименовывается с префиксом Удалить, а в следующем — удаляется полностью).
2. После успешного наката релиза выгружаем файл конфигурации через меню Конфигурация — Сохранить конфигурацию в файл (получаем готовый файл update_release.cf).
3. Блокируем доступ пользователей и регламентных заданий к обновляемым информационным базам.
4. Создаем резервную копию каждой информационной базы.
5. Применяем конфигурацию к базам в пакетном режиме с помощью командной строки.

Посмотрим на пример командного файла пакетного наката конфигурации для клиент-серверной базы:

REM 1. Создание резервной копии информационной базы
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S "server-1c\base_01" /N "Admin" /P "Pass123" /DumpIB "D:\Backups\base_01.dt"

REM 2. Объединение конфигурации с эталонным файлом доработок
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S "server-1c\base_01" /N "Admin" /P "Pass123" /MergeCfg "D:\Releases\update_release.cf"

REM 3. Обновление структуры конфигурации базы данных
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S "server-1c\base_01" /N "Admin" /P "Pass123" /UpdateDBCfg -WarningsAsErrors

REM 4. Запуск процедур обновления данных в режиме предприятия
"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /S "server-1c\base_01" /N "Admin" /P "Pass123" /C ЗапуститьОбновлениеИнформационнойБазы

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

Решение 3. Использование механизма собственной поставки

Для долгосрочной поддержки парка однотипных конфигураций рекомендуется организовать архитектуру собственной поставки:

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