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

← На главную

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

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

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

Многих разработчиков удивляет тот факт, что при использовании команды «Конфигурация — Загрузить конфигурацию из файла» происходит автоматическое обновление конфигурации поставщика (базы, находящейся на поддержке). Давайте разберем этот механизм изнутри.

Файл конфигурации cf — это не просто слепок метаданных основной конфигурации. Если исходная база (из которой выгружался файл cf) стояла на поддержке одного или нескольких поставщиков, то выгруженный файл cf содержит внутри себя полную информацию о конфигурации поставщика (или поставщиков). Когда мы выполняем полную загрузку конфигурации, целевая база полностью заменяется содержимым загружаемого файла. При этом замещается как основная конфигурация базы данных, так и конфигурация поставщика. Именно поэтому система без проблем распознает новые версии поддержки и корректно предлагает следующие файлы обновлений.

Смертельная опасность метода «Загрузить конфигурацию из файла»: конфликт UUID

Несмотря на кажущуюся простоту и корректность работы механизма, метод полной загрузки файла cf («в лоб») таит в себе колоссальную опасность, которая может привести к полной потере данных в добавленных реквизитах или объектах метаданных. Рассмотрим эту проблему детально.

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

Представим типичную жизненную ситуацию в цикле разработки и сопровождения:

На тестовой базе разработчик создает новый реквизит ИНН для справочника Контрагенты. Платформа присваивает этому реквизиту уникальный идентификатор, например: UUID_TEST_111.
В это же время на рабочей базе администратор или другой специалист по срочной просьбе пользователей вручную создает точно такой же реквизит ИНН в том же справочнике с аналогичным типом данных. Платформа генерирует для него другой уникальный идентификатор: UUID_PROD_222. Начинается активная работа, пользователи заполняют этот реквизит данными в рабочей базе.
Спустя время разработчик решает обновить рабочую базу путем операции «Загрузить конфигурацию из файла», используя подготовленный файл cf из тестовой базы.
В процессе загрузки платформа полностью затирает структуру метаданных рабочей базы структурой из файла cf. Реквизит с UUID_PROD_222 (рабочая база) уничтожается, а на его место записывается реквизит с UUID_TEST_111 (из тестовой базы).
При обновлении конфигурации базы данных (клавиша F7) платформа анализирует изменения. С точки зрения системы, объект с идентификатором UUID_PROD_222 был удален пользователем, а абсолютно новый объект с идентификатором UUID_TEST_111 был создан.
Платформа не выдаст ошибок при реструктуризации таблиц, но все накопленные данные в реквизите ИНН на рабочей базе будут безвозвратно удалены, так как колонка старого реквизита в таблице СУБД физически удаляется, а для нового создается пустая колонка.

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

Поведение обработчиков БСП при последовательном обновлении

Современные конфигурации 1С построены на базе Библиотеки стандартных подсистем (БСП). Вся бизнес-логика изменения структуры данных, переноса информации из старых реквизитов в новые, заполнения констант и регистров при обновлении версий выполняется на уровне предприятия специальными обработчиками обновления БСП.

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

Рассмотрим причины, по которым необходимо запускать режим «1С:Предприятие» после наката каждого ключевого релиза:

Удаление устаревшего кода обработчиков. Фирма «1С» регулярно проводит оптимизацию и чистку кода конфигураций. Из состава новых релизов постепенно вырезаются обработчики обновления для очень старых версий. Если вы попытаетесь «перешагнуть» через 10 релизов за раз, в финальном релизе физически может не оказаться кода, который должен был сконвертировать данные из релиза №2 в релиз №3.
Изменение метаданных в промежуточных релизах. Часто при обновлении сложных конфигураций (таких как 1С:ЗУП, 1С:ERP) данные сначала переносятся из Таблицы А в промежуточную Таблицу Б, а в следующем релизе Таблица А полностью удаляется из метаданных. Если вы не запустите систему на промежуточном релизе, у вас одновременно применится структура метаданных без Таблицы А, и переносить данные в Таблицу Б будет просто не из чего. Данные будут потеряны.

Пошаговые методики безопасного и быстрого обновления

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

Методика 1. Подготовка цепочки CF-файлов на тестовой базе (с жестким контролем изменений)

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

Проанализируем шаги выполнения этой методики:

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

Методика 2. Сравнение-объединение и обновление поддержки «вхолостую» (Безопасный метод)

Если у вас есть малейшие сомнения в том, что структура рабочей базы идентична тестовой, либо в рабочую базу могли вноситься ручные изменения объектов, используйте метод сравнения-объединения с последующим обновлением конфигурации поставщика «вхолостую».

Разберем данный алгоритм по шагам:

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

Методика 3. Использование Хранилища конфигурации (для командной разработки)

Для крупных проектов с постоянными доработками и частыми релизами оптимальным решением является использование встроенного инструмента платформы — Хранилища конфигурации. Хранилище гарантирует уникальность UUID всех объектов и исключает риски потери данных.

Посмотрим, как выглядит схема работы с хранилищем при обновлении:

База разработчика подключена к Хранилищу конфигурации. Все новые доработки регистрируются и помещаются в него.
Обновление конфигурации поставщика выполняется на базе разработчика. Разработчик захватывает все объекты, выполняет стандартное обновление, разрешает конфликты кода и помещает обновленную конфигурацию обратно в Хранилище.
Рабочая база также подключается к Хранилищу конфигурации. Для ее обновления администратору достаточно выполнить команду «Конфигурация — Хранилище конфигурации — Получить изменения из хранилища».
Платформа автоматически обновит основную конфигурацию и конфигурацию поставщика. При этом идентификаторы всех объектов гарантированно совпадут с базой разработки, и риск затирания данных будет полностью сведен к нулю.

Как ускорить выполнение процедур БСП?

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

Использование параметров командной строки. Для форсирования выполнения процедур можно запускать 1С в режиме предприятия со специальным ключом запуска /C ВыполнитьОтложенноеОбновлениеСейчас. Это позволит системе сразу запустить фоновые задания обновления в активном сеансе, не дожидаясь расписания регламентных заданий.
Программный запуск через скрипты. Мы можем написать простой командный файл (батник) для автоматизации рутинных запусков. Пример такой команды:


"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" ENTERPRISE /F "C:\Bases\Trade" /N "Admin" /P "Password" /C ВыполнитьОтложенноеОбновлениеСейчас /Visible

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

Подведем итоги

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

Никогда не вносите изменения структуры метаданных в рабочую базу в обход тестовой базы или хранилища, чтобы избежать затирания данных из-за конфликта UUID.
Всегда запускайте рабочую базу в режиме «1С:Предприятие» после наката каждого ключевого cf для корректной отработки механизмов БСП.
Всегда делайте полную резервную копию рабочей базы перед началом любых манипуляций с конфигуратором.