Можно ли обновлять конфигурацию 1С на несколько релизов подряд без запуска режима предприятия?

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

Разница между обновлением метаданных и обновлением данных

Для понимания архитектуры процесса обновления в системе 1С необходимо четко разделять два этапа:

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

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

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

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

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

Если применить конфигурацию релиза N+2 без промежуточного запуска базы на релизе N+1, СУБД физически удалит колонку исходного реквизита. Когда вы запустите предприятие на финальном релизе, обработчик обновления попытается обратиться к объекту УдалитьСуммаВВалюте, но его уже не существует в метаданных. В лучшем случае процесс завершится критической ошибкой, а в худшем — новые реквизиты останутся пустыми, и база продолжит работу с поврежденными данными.

Проанализируем другие критические факторы:

1. Отложенные обработчики обновления: процедуры разделяются на срочные (выполняются монопольно до открытия интерфейса) и отложенные (фоновые, выполняются регламентными заданиями в процессе работы). Если накатить следующий релиз, пока не завершились фоновые задания предыдущего, целостность базы будет нарушена.
2. Изменение режима совместимости: перескок через несколько промежуточных версий может вызвать конфликт с версией платформы или форматом хранения служебных таблиц.
3. Инициализация предопределенных данных: при отсутствии промежуточных запусков возможна рассинхронизация системных ссылок и появление дублей предопределенных элементов.

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

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

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

Автоматизация обновления через командную строку (пакетный режим)

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

Разберем пример пакетных команд для одного шага обновления:

rem Шаг 1. Применение файла обновления метаданных в конфигураторе
"C:\Program Files\1cv8\common\1cv8.exe" DESIGNER /F "C:\Bases\MyBase" /N "Администратор" /P "Пароль123" /UpdateCfg "C:\Updates\1cv8.cfu" /UpdateDBCfg

rem Шаг 2. Запуск срочных процедур обновления данных в режиме предприятия
"C:\Program Files\1cv8\common\1cv8.exe" ENTERPRISE /F "C:\Bases\MyBase" /N "Администратор" /P "Пароль123" /C "ЗапуститьОбновлениеИнформационнойБазы" /DisableStartupMessages

Посмотрим подробнее на используемые параметры запуска платформы:

1. /UpdateCfg <Путь> — указывает путь к файлу поставки обновления (.cfu или .cf) для применения в конфигурации.
2. /UpdateDBCfg — применяет изменения структуры метаданных к текущей базе данных (аналог нажатия F7 в конфигураторе).
3. /C "ЗапуститьОбновлениеИнформационнойБазы" — специальный строковый параметр конфигураций на БСП, инициирующий автоматическое выполнение срочных обработчиков обновления с последующим завершением сеанса.
4. /DisableStartupMessages — отключает показ стартовых диалоговых окон, предупреждений и сообщений об ошибках, блокирующих автоматическое закрытие сеанса.

В случае написания командных файлов (скриптов .bat или .ps1) обязательно анализируем системную переменную ERRORLEVEL после каждого шага. Код возврата 0 свидетельствует об успешном завершении операции. При ненулевом коде возврат сценария следует немедленно прервать, чтобы выяснить причину сбоя в журнале регистрации по событиям с уровнем Ошибка.