При сопровождении сильно кастомизированных систем на платформе 1С:Предприятие 8.3 программисты часто сталкиваются с необходимостью установки сразу целого пакета обновлений. Стандартный путь — последовательное сравнение, объединение и запуск обновления информационной базы (F7) для каждого релиза — может занимать колоссальное количество времени. Возникает закономерный вопрос: можно ли «накатить» все изменения в конфигурацию метаданных один за другим, а процесс реструктуризации таблиц и выполнение программных обработчиков запустить всего один раз в самом конце? Разберем эту ситуацию подробно, проанализируем риски и выясним, в каких случаях такая экономия времени допустима.
Для начала проанализируем, как именно происходит процесс обновления в современных типовых решениях. Большинство из них (Бухгалтерия, ЗУП, ERP, УНФ) построены на базе Библиотеки стандартных подсистем. В БСП встроен специальный механизм, который управляет переходом между версиями. Рассмотрим его работу по шагам:
ВерсииПодсистем.С этой точки зрения «прыжок» кажется безопасным. Однако программные обработчики — это лишь часть процесса. Вторая часть — это физическое изменение структуры таблиц в СУБД (SQL).
Разберем, почему «отложенное» обновление базы данных (клавиша F7 в конфигураторе) может быть опасным. Проанализируем два сценария, в которых часто возникают ошибки при пропуске промежуточных этапов:
1. Потеря данных при переименовании или переносе реквизитов. Представим ситуацию: в релизе №2 разработчики решили отказаться от Реквизита_А и создали Реквизит_Б. Они написали обработчик обновления, который переносит данные из А в Б. В релизе №3 Реквизит_А полностью удаляется из метаданных. Если вы объедините конфигурацию сразу до релиза №3 и только потом нажмете F7, платформа физически удалит колонку Реквизит_А из таблицы SQL. Когда после этого запустится программный обработчик из релиза №2, он попытается прочитать данные из Реквизита_А, но не найдет его. Итог — данные потеряны безвозвратно.
2. Конфликты типов данных. Рассмотрим случай, когда в промежуточном релизе объект удаляется, а в следующем создается объект с таким же именем, но принципиально другим типом (например, из Справочника превращается в Документ). При обновлении «разом» механизм реструктуризации может некорректно сопоставить идентификаторы объектов в SQL-таблицах, что приведет к критическим ошибкам СУБД.
Практика показывает, что «лояльность» к пропуску релизов сильно зависит от конкретного программного продукта. Проанализируем основные решения:
1С:Бухгалтерия предприятия (БП) 3.0: Это наиболее гибкая конфигурация. Разработчики БП часто проектируют обработчики так, чтобы они могли корректно отрабатывать даже при больших скачках версий. В рамках одной редакции (например, 3.0.Х) пропуск нескольких релизов в части обновления базы данных обычно проходит успешно.
1С:Зарплата и управление персоналом (ЗУП) 3.1: Здесь ситуация прямо противоположная. Логика расчета зарплаты и учета периодов крайне сложна. Регистры расчета и накопления в ЗУП очень чувствительны к последовательности изменений. Опытные специалисты настоятельно рекомендуют выполнять обновление базы данных (запуск в режиме Предприятия) после каждого значимого изменения версии, чтобы не «сломать» учетные механизмы.
1С:ERP и Комплексная автоматизация: Из-за масштабных изменений в архитектуре подсистем (например, переход на новые механизмы учета затрат или взаиморасчетов) пропуск обновлений ИБ крайне рискован. Нередки случаи, когда обработчик релиза N требует наличия временных таблиц или объектов, которые удаляются уже в релизе N+1.
Если перед нами стоит задача обновить сильно измененную конфигурацию на большое количество релизов, рассмотрим следующий безопасный и эффективный алгоритм:
.cfu), мы можем взять полный файл конфигурации (.cf) целевого релиза. Это позволит выполнить объединение кода и метаданных всего один раз.Конфигурация — Поддержка — Обновить конфигурацию и «прогнать» последовательность файлов обновления, чтобы система зафиксировала переход по версиям поставщика. Но на этапе сравнения/объединения кода мы можем не тратить время на каждый шаг, а сделать финальное объединение в конце.Update.htm) на предмет удаления объектов или глобальной реструктуризации. Если в списке изменений есть удаляемые реквизиты, обновление ИБ на этом этапе обязательно.Журнал регистрации. Если там есть ошибки с текстом «Обработчик обновления завершился неудачно», значит, выбранная стратегия «прыжка» не подходит для данных версий.Выясним, как программно контролируется процесс обновления. В коде это часто выглядит как вызов определенных методов в модулях типа ОбновлениеИнформационнойБазыБП. Если мы решим анализировать код самостоятельно, обратим внимание на следующие моменты:
// Пример структуры регистрации обработчика в БСП
Процедура ПриДобавленииОбработчиковОбновления(Обработчики) Экспорт
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "3.0.44.15";
Обработчик.Процедура = "ОбновлениеИнформационнойБазыБП.ПеренестиДанныеВНовыйРеквизит";
Обработчик.ОбщиеДанные = Истина;
КонецПроцедуры
Если вы видите, что в конфигурации используется свойство Обработчик.Версия, помните: БСП будет запускать этот код только в том случае, если текущая версия в базе меньше указанной. При «прыжке» через 10 релизов БСП соберет в таблицу сотни таких обработчиков и начнет их выполнять в транзакциях. Важно, чтобы на момент выполнения этих транзакций все необходимые поля в базе данных еще существовали (не были удалены при F7).
Подведем итог нашему анализу:
.cf файл. Это сэкономит время на визуальном сравнении кода.Главное правило: Всегда делайте резервную копию и проверяйте результат с помощью встроенных отчетов «Результаты обновления программы», которые показывают статус выполнения каждого обработчика. Если все обработчики отмечены как «Выполнено», значит, ваш прыжок прошел успешно.