Как обновить рабочую базу 1С оффлайн из предварительно подготовленной тестовой базы?

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

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

Рассмотрим распространенную ошибку: разработчик обновляет тестовую базу, затем выгружает конфигурацию через меню Конфигурация – Сохранить конфигурацию в файл и пытается применить полученный файл в рабочей базе через Конфигурация – Поддержка – Обновить конфигурацию. В результате платформа выдает предупреждение: «Файл не содержит доступных обновлений».

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

Разница между «Загрузить конфигурацию из файла» и «Сравнить, объединить с конфигурацией из файла»

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

1. «Сравнить, объединить с конфигурацией из файла...» — выполняет сопоставление объектов метаданных преимущественно по их именам. Главный недостаток этого метода при обновлении релизов заключается в том, что конфигурация поставщика (базовый эталон для будущих обновлений) не обновляется. Если использовать только объединение, в рабочей базе останется старая версия конфигурации поставщика, что приведет к ошибкам трехстороннего сравнения при следующем релизе.
2. «Загрузить конфигурацию из файла...» — полностью заменяет текущую основную конфигурацию, конфигурацию поставщика и все правила поддержки на те, которые содержатся в загружаемом файле .cf. Сопоставление объектов базы данных выполняется строго по их внутренним идентификаторам (UUID).

Сопоставление метаданных по UUID и сохранение данных

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

Если бы сопоставление происходило по именам, платформа попыталась бы изменить тип существующей колонки таблицы СУБД со строки на ссылку (что привело бы к очистке поля) и добавила бы пустую колонку УдалитьТест. Однако при использовании команды «Загрузить конфигурацию из файла» платформа сверяет метаданные по их внутренним идентификаторам UUID:

1. Платформа видит, что реквизит с прежним UUID теперь называется УдалитьТест, и выполняет в СУБД безопасное переименование физической колонки без потери накопленной информации.
2. Для нового реквизита с новым UUID создается новая колонка.
3. Последующий запуск базы в режиме «Предприятие» корректно считывает данные из УдалитьТест и переносит их в новое поле.

Важнейшее условие: данный механизм работает безопасно только тогда, когда тестовая база была создана как прямая копия (SQL-бэкап или выгрузка .dt) текущей рабочей базы. Если тестовая база собиралась с нуля из пустого файла, UUID объектов разойдутся, и реструктуризация базы данных приведет к удалению и повторному созданию таблиц с полной потерей данных.

Пошаговый регламент обновления рабочей базы

Разберем по шагам правильный алгоритм переноса обновления:

1. Подготовка в тестовом контуре: разворачиваем свежую копию рабочей базы. Штатным образом выполняем обновление конфигурации поставщика (через .cfu или .cf поставщика), адаптируем доработки, выполняем запуск в режиме «Предприятие», применяем обработчики обновления и тестируем функционал.
2. Выгрузка эталона: в конфигураторе обновленной тестовой базы открываем меню Конфигурация – Сохранить конфигурацию в файл... и сохраняем целевой файл update.cf.
3. Создание резервной копии: перед любыми манипуляциями с рабочей базой обязательно создаем полную резервную копию базы данных средствами СУБД или платформы 1С.
4. Загрузка в рабочую базу: завершаем сеансы всех пользователей, открываем конфигуратор рабочей базы и выбираем пункт меню Конфигурация – Загрузить конфигурацию из файла..., указав сохраненный update.cf. Если конфигурация находится на поддержке, платформа выдаст предупреждение о полной замене конфигурации — подтверждаем действие.
5. Контроль окна реорганизации: нажимаем F7 (Обновить конфигурацию базы данных). В открывшемся окне «Реорганизация информации» внимательно анализируем список изменений. Переименованные объекты и реквизиты должны отображаться как модифицируемые, а не удаляемые.
6. Восстановление правил поддержки: после применения изменений открываем окно Конфигурация – Поддержка – Настройка поддержки и убеждаемся, что все объекты установились в те же статусы («на замке», «редактируется с сохранением поддержки»), какие были настроены в тестовой базе.
7. Запуск процедур обновления: запускаем рабочую базу в режиме «1С:Предприятие» под учетной записью с административными правами и дожидаемся завершения регламентных процедур обновления данных.

Автоматизация загрузки через пакетный режим конфигуратора

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

"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER /S "app-server\work_base" /N "Admin" /P "Password123" /DisableStartupMessages /LoadCfg "C:\Updates\update.cf" /UpdateDBCfg

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