Сразу оговорюсь - весь опыт основан на обновлении конфигурации Управление производственным предприятием (УПП), а это обычные формы и отсутствие расширений (так как режим совместимости «Версия 8.2.13»).
Насколько я замечаю по форумам и другим ресурсам по 1с, периодически появляются люди, которым необходимо в короткий срок обновиться через множество версий конфигураций. Причем обычно такие авралы по обновлениям происходят при смене законодательства, то есть, обычно в новый год. И невозможность сделать это за один прием их очень печалит. Надеюсь данная статья позволит избежать таким людям некоторых опрометчивых шагов.
1. Цепочка обновлений.
При обновлении стандартных конфигураций 1с нельзя обновлять с любой версии. По требованиям 1с есть версии с которых можно обновить до нужной. То есть существуют таблицы типа этой.
По этой таблице видно что на версию 1.3.126.2 можно обновляться только с версий 1.3.125.1 и 1.3.126.1. Поэтому для корректного обновления необходимо либо «накатывать» все подряд промежуточные конфигурации либо выстраивать цепочку только необходимых промежуточных конфигураций (насколько помню, на сайте выкладывалась обработка по построению такой цепочки). Причины данного в следующем:
- Одна из основных причин невозможности обновления с пропуском промежуточных конфигураций такова — на сайте 1с (то есть официальном месте раздачи обновлений типовых конфигураций) в большинстве случаев в дистрибутиве обновления лежат файлы с расширением cfu (надеюсь читатель понимает разницу между файлами cf и cfu). А файл cfu содержит только объекты которые были измены. И в обновлении, к примеру, для версии 1.3.124.2 будут только объекты измененные по сравнению с версией 1.3.123.1. Поэтому, в этом случае, пропуск промежуточных конфигураций означает потерю изменений.
Наверняка у некоторых разработчиков мелькнула мысль - на какой-нибудь тестовой базе накатить все обновления, получить конечную конфигурацию, из этой конфигурации создать файл cf и уже им обновить рабочую базу данных (либо тупо найти файл cf нужного релиза). Теоретически возможно, на практике сталкиваемся с следующим пунктом.
- Следующая причина. Это обработчики обновления. Проблемы при пропуске всей цепочки обновления (накатывании сразу финального файла cf) обычно возникают в этом месте. То есть при выполнении обновления конфигурации, при ПЕРВОМ ЗАПУСКЕ В ПОЛЬЗОВАТЕЛЬСКОМ РЕЖИМЕ выполняются обработчики обновления. Это обычные процедуры и функции которые выполняют изменение данных в базе. И если вдруг обработчик обновления обращается к несуществующему объекту или реквизиту, то получаем ошибку. В данном случае несуществующий объект или реквизит - это то что было переименовано или удалено.
Обработчики обновления на примере конфигурации УПП (Управление производственным предприятием).
Кратко суть в следующем — есть список процедур и функций которые вызываются при первом запуске базы данных в пользовательском режиме после обновления конфигурации (так как эти процедуры могут изменить любые данные, то этот запуск должен выполняться под пользователем с полными правами).
*Также обработчики обновления запускаются при первом запуске в пользовательском режиме после создания базы данных.
а). Запуск обработчиков обновления.
В модуле обычного приложения и в модуле управляемого приложения есть Процедура ПриНачалеРаботыСистемы() в которой есть вызов процедуры ОбновлениеИнформационнойБазыКлиент.ВыполнитьОбновлениеИнформационнойБазы(). Если конфигурация изменилась, то начинаются процедуры формирования списка обработчиков обновления, а затем выполнения полученных обработчиков из списка. Изменение конфигурации, в общем случае, определяется как различие значений версий "новой" и "старой" конфигураций. Значение "старой" (это значение до обновления) версии конфигурации хранится в базе данных.
б). Данные по версиям конфигурации и библиотек/подсистем.
В УПП данные по версиям (значения до обновления) хранятся в самой базе данных в регистре сведений ВерсииПодсистем.
Новые значения версий получают следующим образом - для самой конфигурации это значение Метаданные.Версия (по сути это реквизит "Версия" в свойствах конфигурации), для библиотек и подсистем данные получаются из функций. Для библиотеки УПП пример приведен ниже.
//в общем модуле БиблиотекаОбновленияИнформационнойБазы
// Возвращает номер версии Библиотеки УПП
Функция ВерсияБиблиотеки()
Возврат "1.3.124.2";
КонецФункции
При успешном обновлении новые значения версий записываются в регистр сведений.
в). Списки обработчиков обновлений.
Получаются из функций (в УПП стандартно называются ОбработчикиОбновления, и, скорее всего, это стандартное наименование в типовых конфигурациях).
//в общем модуле БиблиотекаОбновленияИнформационнойБазыПереопределяемый
// Возвращает список процедур-обработчиков обновления ИБ для всех поддерживаемых версий ИБ.
//
// Пример добавления процедуры-обработчика в список:
// Обработчик = Обработчики.Добавить();
// Обработчик.Версия = "1.0.0.0";
// Обработчик.Процедура = "ОбновлениеИБ.ПерейтиНаВерсию_1_0_0_0";
//
// Вызывается перед началом обновления данных ИБ.
//
Функция ОбработчикиОбновления() Экспорт
Обработчики = ОбновлениеИнформационнойБазы.НоваяТаблицаОбработчиковОбновления();
// Библиотеки УПП и ЗУП
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "*";
Обработчик.Процедура = "БиблиотекаОбновленияИнформационнойБазы.ВыполнитьОбновлениеИнформационнойБазы";
// Библиотека обмена ЭД
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "*";
Обработчик.Процедура = "ОбновлениеИнформационнойБазыЭД.ВыполнитьОбновлениеИнформационнойБазы";
// Библиотека ЕГАИС
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "*";
Обработчик.Процедура = "ОбновлениеИнформационнойБазыЕГАИС.ВыполнитьОбновлениеИнформационнойБазы";
// Библиотека МОТП
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "*";
Обработчик.Процедура = "ОбновлениеИнформационнойБазыМОТП.ВыполнитьОбновлениеИнформационнойБазы";
// При создании новой базы
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "1.3.1.1";
Обработчик.Процедура = "Справочники.СпособыРаспределенияЗатратНаВыпуск.ЗаполнитьСпособыРаспределенияПоУмолчанию";
...
Для некоторых подсистем список обработчиков зависит от того, главный это узел обмена или подчиненный.
//для библиотеки ЗУП
//общий модуль ПроцедурыОбновленияИнформационнойБазыПереопределяемый
Функция ОбработчикиОбновления()
Обработчики = ОбновлениеИнформационнойБазы.НоваяТаблицаОбработчиковОбновления();
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "*";
Обработчик.Процедура = "ПроцедурыОбновленияИнформационнойБазы.ЗагрузитьНастройкиОтчетов";
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "2.5.1.1";
Обработчик.Процедура = "ПроцедурыОбновленияИнформационнойБазыПереопределяемый.ПервыйЗапуск";
ЭтоНеПериферияРИБ = Не ЗначениеЗаполнено(ПланыОбмена.ГлавныйУзел());
// 2.5.39.1
Если ЭтоНеПериферияРИБ Тогда
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "2.5.39.1";
Обработчик.Процедура = "ПроцедурыОбновленияИнформационнойБазыПереопределяемый.УстановитьКодЭлементаРасходыПоУплатеСтраховыхВзносов";
Обработчик.Опциональный = Истина;
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "2.5.39.1";
Обработчик.Процедура = "ПроцедурыОбновленияИнформационнойБазыПереопределяемый.ОбновитьРегистрСведенийСсылкиНаСайтеИТС";
Обработчик.Опциональный = Истина;
КонецЕсли;
...
В УПП структура обработчиков имеет 9 полей. В подавляющем большинстве случаев используется 2 - "Версия" и "Процедура". Иногда используются поля "Опциональный" и "Приоритет" (в частности в подсистеме ЕГАИС). Поэтому при необходимости надо смотреть логику формирования списка обработчиков для конкретных случаев.
//общий модуль ОбновлениеИнформационнойБазы
Функция НоваяТаблицаОбработчиковОбновления() Экспорт
Обработчики = Новый ТаблицаЗначений;
Обработчики.Колонки.Добавить("НачальноеЗаполнение", Новый ОписаниеТипов("Булево"));
Обработчики.Колонки.Добавить("Версия", Новый ОписаниеТипов("Строка", Новый КвалификаторыСтроки(0)));
Обработчики.Колонки.Добавить("Процедура", Новый ОписаниеТипов("Строка", Новый КвалификаторыСтроки(0)));
Обработчики.Колонки.Добавить("Опциональный");
Обработчики.Колонки.Добавить("Приоритет", Новый ОписаниеТипов("Число", Новый КвалификаторыЧисла(2)));
Обработчики.Колонки.Добавить("ОбщиеДанные", Новый ОписаниеТипов("Булево"));
Обработчики.Колонки.Добавить("УправлениеОбработчиками", Новый ОписаниеТипов("Булево"));
Обработчики.Колонки.Добавить("ВыполнятьВГруппеОбязательных", Новый ОписаниеТипов("Булево"));
Обработчики.Колонки.Добавить("МонопольныйРежим");
Возврат Обработчики;
КонецФункции
Если Обработчик.Версия=«*», то данная процедура будет занесена в первоначальный список при любом обновлении. Если в этом параметре версия указана, то в первоначальный список данная процедура будет занесена при обновлении на данную версию (либо эта версия промежуточная при обновлении). В дальнейшем из списка процедуры могут быть исключены (в частности в зависимости от параметра "Опциональный").
В параметре Обработчик.Процедура указаны либо процедуры из общего модуля ("БиблиотекаОбновленияИнформационнойБазы.ВыполнитьОбновлениеИнформационнойБазы" — это процедура ВыполнитьОбновлениеИнформационнойБазы() из общего модуля БиблиотекаОбновленияИнформационнойБазы) либо процедура из модуля менеджера объекта ("Справочники.СпособыРаспределенияЗатратНаВыпуск.ЗаполнитьСпособыРаспределенияПоУмолчанию" - Процедура ЗаполнитьСпособыРаспределенияПоУмолчанию() из модуля менеджера справочника СпособыРаспределенияЗатратНаВыпуск).
г). Цепочка вызовов процедур и функций при формировании списка обработчиков обновления.
Так как подсистем может быть несколько (что видно по регистру ВерсииПодсистем), то для каждой подсистемы формируется свой список обработчиков обновлений. Основной путь для конфигурации УПП показан ниже. Для других конфигураций этот путь может быть совсем иным.
//основные моменты формирования и выполнения обработчиков обновления для конфигурации УПП
И в модуле обычного приложения и в модуле управляемого приложения
Процедура ПриНачалеРаботыСистемы()
ОбновлениеИнформационнойБазыКлиент.ВыполнитьОбновлениеИнформационнойБазы();
ОбновлениеИнформационнойБазы.ВыполнитьОбновлениеИнформационнойБазы()
НеобходимоВыполнитьОбновление(ВерсияМетаданных, ВерсияДанных) //проверка на необходимость выполнения обработчиков обновления
//ряд процедур подготовки выполнения (процедуры проверки полных прав пользователя, попытка установить монопольный режим и т.п.
ОбновлениеИнформационнойБазыПереопределяемый.ОбработчикиОбновления();
БиблиотекаОбновленияИнформационнойБазыПереопределяемый.ОбработчикиОбновления(); //список обработчиков выполнения
//Код данной процедуры можно увидеть в предыдущем подпункте. В коде видно что для каждой библиотеки идет вызов своей ветки обработчиков.
//добавление еще одного блока обработчиков обновления из СтандартныеПодсистемыСервер.ВыполнитьОбновлениеИнформационнойБазы
ВыполнитьИтерациюОбновления()
ОбновлениеИнформационнойБазыПереопределяемый.ПослеОбновления() //в УПП выход на пустую процедуру
д). Подсистемы БСП.
Плотно не изучал данный вопрос. Поверхностно просматривая одну из конфигураций БСП видел там процедуры ПередОбновлениемИнформационнойБазы и ПослеОбновленияИнформационнойБазы. Вроде бы эти процедуры были без содержания, но, насколько я понял, такие процедуры присутствуют чуть ли не у каждой подсистемы. Так что учитывайте присутствие подсистем БСП в своей конфигурации.
Переименования и удаления объектов и реквизитов, как правило, происходит в момент создания чего-то нового. Что-то создается, а потом на основе практики часть функционала переделывается. Так было, например, при создании системы ЕГАИС.
Либо над конфигурацией работает несколько групп разработчиков у которых отвратительное взаимодействие. И получается что-то вроде истории про справочник ПакетЭДПрисоединенныеФайлы в конфигурации УПП (обратите внимание на последние две строки на картинке).
Но, насколько я вижу по конфигурации УПП, разработчики также поняли что при удалении объектов могут возникнуть проблемы (в частности возможность потери пользовательских данных — набили данные в регистр сведений, а он в следующем релизе «исчез»). Поэтому у объектов просто в названии приписывают спереди слово "Удалить".
2. Обновление платформы.
Также следует учесть следующий момент. Иногда обновление конфигурации требует одновременно обновить платформу. Например
То есть в данном случае потенциально намечается переход с платформы 8.2.19.130 на 8.3.12. А при переходе с платформы на платформу в разделе «Список изменений и порядок обновления» начинаем изучать пункты «Переход с предыдущей версии на версию ...». Потому как там есть много интересного. Например при обновлении платформы до версии 8.3.8 есть в частности:
При установке свойства Режим совместимости в значение Не использовать, минимальной версией СУБД Microsoft SQL Server (в том числе и при использовании Native Client), с которой будет работать «1С:Предприятие», становится Microsoft SQL Server 2005.
- Если переход на текущую версию системы «1С:Предприятие» выполняется:
С версии из интервала между 8.3.8.1606 и 8.3.8.1861 (включая обе граничные версии) - рекомендуется воспользоваться утилитой административной консоли (1cv8a) или выполнить операцию тестирования и исправления с включенным флажком Проверка логической целостности (если любая из указанных операций еще не выполнялись после перехода).
- При переходе на систему «1С:Предприятие» версии 8.3.8 и старше, рекомендуется воспользоваться специальной обработкой, размещенной на диске ИТС (см. здесь). Результатом работы обработки является информация о том, нужно или нет выполнять пересчет итогов для устранения некорректного расчета итогов для регистров накопления и бухгалтерии, если среди измерений есть хотя-бы одно измерение с типом Строка и в состав индекса по измерениям входят более 16 полей базы данных. Если пересчет итогов нужен, необходимо однократно (после перехода на новую версию) выполнить операцию тестирования и исправления с включенными флажками Проверка логической целостности информационной базы и Пересчет итогов или воспользоваться утилитой административной консоли (1cv8a). В случае использования утилиты необходимые действия будут выполнены быстрее. В документации данное изменение описано здесь.
(Источник. https://dl03.1c.ru/content/Platform/8_3_15_1700/1cv8upd_8_3_15_1700.htm#5a3feda5-6292-11e5-a3f7-0050569f678a )
Обновление платформы может резко осложниться если у вас серверная 1с и на одной платформе функционирует несколько баз данных, при этом ряд баз за прошлые периоды (то есть не обновляются). Вопросы которые желательно решить до обновления платформы: 1)поддерживают ли базы данных за прошлые периоды новую платформу; 2)если у этих баз "своя" защита данных, поддерживает ли эта защита данных новую платформу. Если по одному из пунктов не поддерживает, то возможные варианты решения: 1)если нужно быстро и временно решить проблему - при возможности (небольшая база, мало пользователей, нечасто используется) базу перевести в файловый режим на расшаренный сетевой ресурс; 2)создать новый сервер 1с под новую платформу на отдельном физическом сервере; 3)создать сервер 1с новой платформы на том же физическом сервере где расположен сервер 1с старой платформы (статья есть на этом сайте).
3. Конфигурация как объединение нескольких типовых конфигураций либо типовая конфигурация с значительными доработками.
Все резко усложняется если ваша конфигурация состоит из нескольких типовых конфигураций. Может возникнуть ситуация что одна типовая конфигурация требует новой версии платформы, а другая типовая конфигурация не поддерживает эту новую версию платформы. Либо есть типовая конфигурация с большими доработками. И эти доработки не поддерживают новую платформу. В обоих случаях придется рассматривать возможность переписывать конфигурацию под требования новой версии технологической платформы.
Но перед тем как переписывать конфигурацию под новую версию платформы рассмотрите следующий момент. Нередко конфигурации используют свою защиту. Если у вас такая конфигурация, со своей защитой, выясните поддерживает ли эта защита новую платформу (может быть беда если конфигурация снята с поддержки).
4. Наличие обменов.
Ничего не могу сказать об обменах основанных на КД. Имел практику с обменами РИБ и древним нестандартным обменом.
Если используется типовой обмен РИБ, то это означает что в подчиненных узлах используется такая же конфигурация что и в главном узле. И стандартный процесс обновления выглядит следующим образом — обновление на главном узле, затем по обмену это обновление уходит на подчиненные узлы. Узлы принимают обновление, выполняют первый запуск под полными правами (для отработки обработчиков обновлений) и формируют ответный файл обмена с сообщением что изменения конфигурации приняты. И после приема главным узлом этого сообщения от всех подчиненных узлов можно выполнять следующее обновление конфигурации. Выполнение обмена не по стандарту потенциально есть путь бессонным ночам и дикому напрягу (короче я предупредил).
Все следующее это мои размышления не подкрепленные практикой (то есть, если примените и вдруг что-то не сработает — сам дурак). Потенциально подчиненными узлами можно пропустить некоторые обновления конфигурации. Во-первых, главный узел формирует файл с изменениями конфигурации для подчиненных узлов от последнего факта передачи изменения конфигурации каждому подчиненному узлу. То есть все изменения конфигурации в главном узле придут по обмену в подчиненный узел (упрощенно. Начальный момент - у главного и подчиненного узла единая конфигурация. После этого главный узел обновил конфигурацию (без разницы сколько раз). После этого главный узел будет формировать файл обмена со ВСЕМИ изменениями конфигурации до того момента как получит от подчиненного узла подтверждение о принятии изменений конфигурации). Во-вторых, если ВСЕ обработчики обновления изменяют данные которые также «ходят» по обмену, то, в принципе, пропуск передачи этого обновления в подчиненный узел не критичен. Пример — обработчик изменения модифицирует справочник Банки. Если справочник Банки «ходит» по обмену, то в головном узле изменения будут выполнены, а затем эти измененные элементы справочника «придут» в подчиненный узел. Если справочник Банки не «ходит» по обмену, то в головном узле изменения будут выполнены, а в подчиненном узле пропуск обновления конфигурации может привести к описанным ранее проблемам (изменение имени, удаление объекта или реквизита).
Если обмен не РИБ, но при этом обмене используется передача объектов целиком (довольно редкий случай, насколько я понимаю все таки наиболее часто используются обмены РИБ и обмены основанные на КД). При таких обменах элементы для обмена получают с помощью ПолучитьОбъект() и, как правило, в виде записи XML помещают в файл обмена. Такие обмены подразумевают что структура элементов которые обмениваются идентична (даже изменение порядка реквизитов в структуре объекта либо останавливает обмен либо делает обмен не полным). То есть сами конфигурации могут сильно отличаться. Во всем, кроме объектов которые стоят на обмене. При наличии таких обменов просто надо контролировать идентичность структуры обмениваемых объектов.
5. Обновление сразу нескольких релизов на рабочую базу.
Если ваша конфигурация не типовая либо типовая с доработками. Сильно не рекомендую накатывать оптом несколько версий релизов сразу на рабочую базу. Даже при наличии тестирования конфигурации перед обновлением рабочей базы случаются ошибки. Если есть время и возможность, накатили версию — смотрим рабочий день, два. Затем следующее обновление. Потому что чем больше изменений в конфигурации, тем тяжелее найти причины возникающих ошибок.
6. Дополнения.
Как вносить обновления в саму конфигурацию это отдельная и большая тема. Про это написано немало. Так что просто укажу грабли которые больно били мне голове и лайфхаки на которые я хотел бы обратить внимание.
6.1. Обновление за один раз.
Если в конфигурации сделано множество изменений и дополнений, то внести обновления за раз может и не получиться. А держать открытым окно сравнения и объединения день и больше это чревато (как говорится - кто не терял свою работу за день, то не поймет). Поэтому за первый проход объединял объекты которые не были затронуты изменениями. Плюс "легкие" изменения. Если же надо смотреть логику кода - оставлял на следующие шаги. Сохранил изменения, сохранил измененную конфигурацию - разбираюсь с сложными объектами (например когда в модуле формы добавлено больше 10 новых процедур и функций плюс изменено больше 10 процедур и функций). При этом у меня были открыты три конфигуратора - 1)конфигуратор с окном сравнения новой и старой типовыми конфигурациями; 2)конфигуратор с окном сравнения старой рабочей конфигурации и старой типовой конфигурации; 3)конфигурация разработки. В 1 конфигураторе видна логика работы типовой конфигурации, во 2 конфигураторе видна логика нашей конфигурации. В принципе окна сравнения можно открыть в одном конфигураторе, но иногда требуется открыть кучу дополнительных окон (общие модули, формы и проч.) и тогда становится сложно разбираться какое окно к какой конфигурации относится.
6.2. Несоответствия цветов на окне сравнения/объединения конфигураций.
Почему это так я не знаю. Может это баг платформы и в какой-то новой платформе его пофиксили, может это последствия неграмотного обновления в прошлом. Но у меня не один раз возникало следующее.
Обновление УПП с 1.3.124.1 на 1.3.124.2 (измененных объектов очень мало).
А вот окно обновления конфигурации. По дефолту общий модуль ИнтеграцияЕГАИССлужебныйКлиент не становится на обновление, хотя он в нашей конфигурации не изменялся. Можно заметить отличающийся квадратик в левой части, но у меня различающихся объектов порядка 10000, поэтому все просматривать весьма утомительно.
Плюс маленькая засада для юных падованов - дважды измененные объекты никак не выделяются на общей картине (смотреть на ветку Документы). И если начинающий специалист по обновлениям не знает куда смотреть то он может упустить это.
6.3. Порядок объектов.
Не путать с порядком реквизитов объекта - порядок реквизитов может быть критичен в некоторых обменах данными.
Всегда делаю порядок всех видов объектов по алфавиту. Потому что если в новой типовой конфигурации вдруг изменили порядок ОДНОГО объекта, то окно сравнения и объединения покажет кучу строк с изменившимися объектами. По сути порядок объектов важен только для удобства - логике программы без разницы что выше справочник Вакансии или справочник Бюджеты. Но при сравнении это выделяется и никак отключить нельзя. А высматривать среди сотен строк "Порядок объекта изменен" действительно значимые изменения весьма некомфортно. Можно для упрощения в типовой конфигурации также выстроить все объекты по алфавиту и после этого сравнивать.
6.4. Изменения типовой процедуры измененного объекта (одна из граблей).
Желательно смотреть логику. Тут все становится понятно на примере.
Документ ОтражениеЗарплатыВРегУчете. Модуль объекта. Дописали процедуру ПолучитьПроводкиПоСтраховымВзносам2014(). И однажды получаем сообщение что неправильно проводки считаются, без наших изменений. Оказалось - с нового года используется процедура ПолучитьПроводкиПоСтраховымВзносам2016(). Просто при обновлении посмотрели - дописанные нами процедуры меняются - нет, вот и хорошо. А то что изменилась процедура АвтозаполнениеПроводок() (из которой вызываются вышеуказанные процедуры) - так она типовая, автоматом обновляем.
Вот примерно так. Думаю в комментариях укажут и другие ключевые моменты обновлений типовых конфигураций (и типовых дописанных).
