Обновление конфигураций 1С, которые содержат значительное количество пользовательских правок, — это всегда сложный и ответственный процесс. Ситуация осложняется, если необходимо «перепрыгнуть» через несколько релизов сразу. В этой статье мы подробно рассмотрим методики, которые позволяют минимизировать риски потери данных и корректно перенести доработки в новую версию системы.
Первый вопрос, который возникает у разработчика: можно ли просто загрузить финальный файл конфигурации cf последнего релиза или нужно последовательно применять каждый промежуточный файл обновления cfu? Рассмотрим оба подхода.
Загрузка финального CF: Этот метод кажется самым быстрым. Вы готовите на копии базы итоговую конфигурацию, в которой совмещены типовой функционал последнего релиза и ваши доработки, а затем загружаете её в рабочую базу через «Сравнить и объединить» или «Загрузить конфигурацию из файла».
Пошаговое обновление: Здесь каждый релиз накатывается последовательно. Этот путь более трудозатратный, но он считается максимально безопасным с точки зрения платформенных механизмов.
Проанализируем ситуацию: файл cf действительно содержит полную структуру метаданных. Однако обновление программы — это не только изменение структуры таблиц в базе данных, но и выполнение программного кода, который трансформирует данные. Выясним, почему «прыжок» через релизы может быть опасен.
Основная опасность при обновлении «скачком» заключается в работе механизмов Библиотеки стандартных подсистем (БСП). В каждой современной конфигурации 1С существует регистр сведений ВерсииПодсистем. При запуске системы после обновления программный код сравнивает версию в коде и версию в этом регистре.
Рассмотрим критический пример. Предположим, в релизе 001 адрес контрагента хранился в Реквизите справочника. В релизе 002 разработчики 1С решили перенести адреса в РегистрСведений. Для этого они написали обработчик обновления, который при первом запуске релиза 002 переносит данные из реквизита в регистр. В релизе 003 старый Реквизит окончательно удаляется из метаданных.
Если мы обновим базу сразу с релиза 001 на 003 путем загрузки cf:
Поэтому, если вы решили использовать финальный cf, крайне важно убедиться, что система корректно отработает цепочку всех пропущенных обработчиков обновления. В типовых конфигурациях (например, БП 3.0) разработчики стараются сохранять обработчики долго, но риск остается.
Для безопасного обновления сильно измененных баз рекомендуется использовать методику подготовки эталонного файла конфигурации на отдельной копии. Разберем этот процесс по шагам:
cf целевого релиза со всеми корректными идентификаторами.cf «Версии Б».Чтобы в будущем процесс обновления не занимал недели, проанализируем возможность выноса доработок из основной конфигурации. Современная платформа 1С предоставляет для этого мощный инструмент — расширения конфигурации.
Рассмотрим пример правильной архитектуры доработок. Вместо того чтобы менять типовой модуль, мы можем использовать аннотацию &Вместо или &После в расширении:
&Вместо("РассчитатьСуммуДокумента")
Процедура Мой_РассчитатьСуммуДокумента(Параметры)
// Сначала вызываем типовую логику, если нужно
ПродолжитьВызов(Параметры);
// Добавляем свою логику расчета
Сумма = Параметры.Сумма * 1.15;
КонецПроцедуры
Также рекомендуется минимизировать визуальные правки форм в конфигураторе. Вместо этого можно изменять формы программно в расширении, используя событие ПриСозданииНаСервере. Это позволит типовой форме обновляться без конфликтов, а ваши элементы будут добавляться динамически.
Если правок в коде действительно много, стандартное окно сравнения и объединения становится неэффективным. Рассмотрим использование 1С:EDT (Enterprise Development Tools) и систем контроля версий (Git).
Использование Git позволяет выполнять так называемое «трехстороннее слияние» (3-way merge). Система сравнивает три состояния: «старая типовая», «ваша доработанная» и «новая типовая». Большинство изменений кода, которые не пересекаются в одних и тех же строках, Git объединит автоматически, и вам останется разрешить только реальные логические конфликты.
Посмотрим на процесс с использованием EDT:
При анализе доработок обратите внимание на механизмы БСП. Разработчики 1С специально оставляют модули с постфиксом Переопределяемый (например, ОбщегоНазначенияПереопределяемый). Если логику можно встроить в эти модули, делайте это именно там. При обновлении эти модули реже претерпевают кардинальные изменения структуры, что упрощает поддержку.
Когда «Золотой образ» готов и протестирован, наступает этап обновления живой базы. Чтобы работа клиента не встала на длительный срок, придерживайтесь следующих правил:
cf. Это займет значительно меньше времени, чем ручное объединение модулей «на лету».cf и перед запуском первого обновления данных создавайте полные дампы базы.Таким образом, успех обновления нетиповой конфигурации зависит от тщательной подготовки «Золотого образа» на копии, понимания работы обработчиков БСП и постепенного перехода на использование расширений для изоляции кастомного кода от типового ядра.