← На главную

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

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

Ошибочный подход: почему нельзя обновлять рабочую базу напрямую через «Сравнить и объединить»

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

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

Правильная методика подготовки обновления на локальном компьютере

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

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

Перенос подготовленного обновления на рабочую базу

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

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

Дополнительные технические факторы, требующие контроля

Разберем специфические моменты, которые могут помешать корректной загрузке конфигурации:

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