При работе с распределенной инфраструктурой или поддержкой нескольких однотипных баз (например, Бухгалтерия предприятия 2.0) использование хранилища конфигурации является стандартом разработки. Однако процесс массового обновления баз из хранилища таит в себе подводные камни, особенно если требуется «перепрыгнуть» через несколько релизов сразу. В этой статье мы подробно разберем оптимальный алгоритм действий, проанализируем риски и рассмотрим способы автоматизации этого процесса.
Рассмотрим ситуацию, когда у нас есть одна конфигурация, находящаяся в хранилище, и несколько рабочих баз, которые к нему подключены. Нам необходимо обновить рабочие базы до актуальной версии, учитывая, что в хранилище может быть помещено последовательно несколько релизов (например, обновление с версии 2.0.64 до 2.0.66 через 2.0.65).
Типовой цикл обновления в Конфигураторе выглядит следующим образом:
Проанализируем вопрос о последовательности. Если в хранилище зафиксировано два обновления подряд, можно ли обновить рабочую базу один раз сразу до последней версии? Ответ: технически — да, метаданные обновятся. Но с точки зрения данных — это опасно. Разберем, почему.
Основная сложность при обновлении типовых конфигураций 1С (особенно уровня БП 2.0) заключается не в изменении структуры таблиц, а в обработчиках обновления данных. Это программный код, который выполняется в режиме «Предприятие» при первом запуске после обновления. Он переносит данные из старых реквизитов в новые, заполняет новые константы и справочники.
Если мы обновляем конфигурацию через хранилище сразу на три релиза вверх, то при запуске «Предприятия» система может попытаться запустить обработчики сразу для всех версий. В некоторых конфигурациях логика этих обработчиков жестко завязана на последовательность. Если код релиза 2.0.66 ожидает, что данные уже были преобразованы обработчиком из 2.0.65, а мы этот этап пропустили в режиме «Предприятие», это может привести к потере информации или логическим ошибкам в учете.
Рекомендованная схема действий:
Для обеспечения максимальной стабильности мы рекомендуем придерживаться следующего цикла для каждого релиза:
Пока ЕстьСледующийРелиз Цикл
// Накатываем релиз в базу разработчика
ОбновитьКонфигурациюИзФайла(ПутьКФайлуОбновления);
// Фиксируем изменения в хранилище
ПоместитьВХранилище(ВсеОбъекты);
// Для каждой рабочей базы
Для Каждого База Из РабочиеБазы Цикл
ОбновитьИзХранилища(База);
ОбновитьКонфигурациюБД(База);
// ВАЖНО: Запуск в режиме Предприятие для отработки кода обновления
ЗапуститьПредприятиеИЖдатьЗавершения(База);
КонецЦикла;
КонецЦикла;
Если рабочих баз много, ручное обновление каждой через меню Конфигурация -> Хранилище конфигурации -> Обновить конфигурацию из хранилища становится непозволительно долгим процессом. Рассмотрим, как автоматизировать этот процесс с помощью командной строки. Мы можем использовать пакетные файлы (.bat или .cmd).
Основные ключи для работы с хранилищем:
/ConfigurationRepositoryF — путь к каталогу хранилища./ConfigurationRepositoryN — имя пользователя в хранилище./ConfigurationRepositoryP — пароль пользователя./ConfigurationRepositoryUpdateCfg — команда получения изменений./UpdateDBCfg — применение изменений к базе данных (F7).Пример скрипта для автоматического обновления одной базы:
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S "Server\BaseName" /N "Admin" /P "Pass" /ConfigurationRepositoryF "\\Server\Repo" /ConfigurationRepositoryN "RepoUser" /ConfigurationRepositoryP "RepoPass" /ConfigurationRepositoryUpdateCfg /UpdateDBCfg /Out "C:\Logs\update.log"
Проанализируем ситуацию: использование ключа /ConfigurationRepositoryUpdateCfg позволяет получить актуальную версию из хранилища без открытия визуального интерфейса. Добавление ключа /UpdateDBCfg завершает процесс обновления структуры базы данных.
Иногда прямое подключение всех рабочих баз к хранилищу может быть неэффективным (например, из-за медленных каналов связи или большого размера хранилища). Рассмотрим альтернативный, часто более надежный метод:
.cf) через меню Конфигурация -> Сохранить конфигурацию в файл..cf для пакетного обновления всех рабочих баз.Команда для обновления из файла:
DESIGNER /F "C:\Bases\WorkBase" /LoadCfg "C:\Releases\v1.cf" /UpdateDBCfg
Этот метод хорош тем, что файл .cf — это «чистая» конфигурация без истории изменений хранилища, что уменьшает объем передаваемых данных и снижает риск возникновения ошибок кеша метаданных.
Выясним причину, по которой многие системные администраторы опасаются динамического обновления (так называемого «обновления на лету», когда в базе есть пользователи). При обновлении из хранилища система может предложить обновить конфигурацию базы данных динамически. В случае с БП 2.0 и любыми сложными конфигурациями мы настоятельно рекомендуем этого избегать.
Риски динамического обновления:
Поэтому перед запуском процесса обновления из хранилища необходимо обеспечить монопольный доступ к базе. В скриптах автоматизации для этого можно использовать команду отключения пользователей через COM-соединение или утилиту taskkill для завершения активных сеансов.
Разберем ситуацию, когда хранилище начинает работать медленно. При каждом помещении релиза (особенно если вы помещаете не измененные объекты, а всю конфигурацию целиком через сравнение-объединение) размер хранилища растет. Рассмотрим шаги по его оптимизации:
Администрирование хранилища можно выполнить сокращение истории, удалив старые, неактуальные версии. Это значительно ускоряет получение обновлений рабочими базами.Мы проанализировали процесс обновления баз, подключенных к хранилищу, и пришли к выводу, что наиболее безопасным является последовательный метод. Давайте закрепим основные правила совместной работы:
Соблюдение этих простых, но эффективных правил позволит вам избежать критических ошибок при эксплуатации систем на платформе 1С и обеспечит актуальность данных во всех ваших информационных базах.