← На главную

Обновление нетиповой конфигурации 1С, находящейся на поддержке с возможностью изменения и отставшей на 10–15 релизов от актуальной версии, представляет собой сложную инженерную задачу. Попытка обновиться «одним кликом» или сразу накатить финальный файл поставщика без предварительной подготовки неизбежно приводит к потере доработок, ошибкам реструктуризации СУБД и падению регламентных процедур миграции данных. Разберем по шагам надежные сценарии и правила обновления таких систем.

Анализ рисков при обновлении через несколько релизов

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

1. Удаление и замена реквизитов поставщиком: если между релизами разработчик типового решения удалил реквизит или заменил его новым регистром, прямой накат приведет к физическому удалению старой колонки в таблицах СУБД с безвозвратной утратой информации.
2. Сбои в процедурах обновления информационной базы: механизмы миграции данных (обработчики обновления ИБ) рассчитаны на последовательную цепочку версий. Если алгоритм промежуточного релиза обращается к объекту, удаленному в финальной версии, регламентная процедура завершится аварийно.
3. Колоссальная нагрузка на СУБД: накопленная за много релизов реструктуризация приводит к разрастанию журнала транзакций СУБД и переполнению системных баз данных (например, tempdb в MS SQL Server).

Подготовка базы данных к процедуре обновления

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

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

Методика 1: Пошаговое обновление с использованием трех баз и внешнего диффера

Рассмотрим классический и наиболее надежный способ последовательного переноса правок при сильной модификации модулей и объектов:

1. Разворачивание трех конфигураций:

   Для полного визуального контроля создаем три базы в Конфигураторе:

   1. Исходная рабочая конфигурация со всеми доработками заказчика.

   2. Исходная чистая конфигурация поставщика того же релиза, на котором сейчас находится база.

   3. Рабочая копия для выполнения обновления.

2. Определение дважды измененных объектов:

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

3. Слияние кода через внешний инструмент (KDiff3):

   Для общих модулей, модулей объектов и менеджеров используем трехстороннее сравнение с помощью KDiff3 или аналогичных утилит слияния. Это позволяет безошибочно сопоставить код исходного поставщика, код нового релиза поставщика и пользовательские правки.

4. Обработка форм и визуальных элементов:

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

5. Применение изменений и запуск предприятия:

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

Методика 2: Метод эталонного файла конфигурации поставщика (CF)

Проанализируем ситуацию, когда пошаговое открывание окна сравнения на 14 релизов отнимает слишком много времени. Для ускорения процесса объединения метаданных применим технологию единого эталонного .cf:

1. Подготовка целевого релиза поставщика: в отдельной чистой пустой базе последовательно накатываем все 14 релизов через файлы обновлений .cfu или .cf. Запускать режим предприятия для пустой базы на промежуточных этапах не требуется.
2. Выгрузка чистого CF: из подготовленной пустой базы выгружаем итоговый файл конфигурации поставщика целевого релиза.
3. Трехстороннее объединение за один шаг: в доработанной базе открываем меню Конфигурация — Поддержка — Обновить конфигурацию и указываем полученный итоговый .cf. Платформа самостоятельно сопоставит начальную конфигурацию поставщика, текущую доработанную версию и целевой релиз. Конфликты в коде разрешаются один раз, а не 14.
4. Последовательный прогон обработчиков данных: если между релизами произошли кардинальные перестроения структур учета, после обновления конфигурации накатываем промежуточные файлы .cf порциями (например, через 4–5 релизов) с обязательным запуском предприятия после каждого шага для отработки регламентных процедур миграции.

Специфика переноса метаданных и форм

Разберем особенности переноса изменений различных типов объектов:

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

Минимизация времени простоя (Downtime) рабочей базы

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

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

Рекомендации по доработке конфигураций для будущих обновлений

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

1. Отказ от изменения тел типовых процедур: вместо правок в модулях типовых документов и справочников используем механизм ПодпискиНаСобытия (например, ОбработкаПроведения, ПередЗаписью, ПриУстановкеНовогоНомера) и выносим бизнес-логику в отдельные самописные общие модули.
2. Программное создание элементов формы: новые поля и кнопки на формах создаем программно в процедуре ПриОткрытии или ПриСозданииНаСервере, оставляя типовую форму неизменной в дереве метаданных.
3. Вынос отчетов и печатных форм: печатные формы и модифицированные отчеты подключаем через механизмы дополнительных внешних отчетов и обработок, не снимая типовые объекты с поддержки.
4. Четкая маркировка правок: если изменение типового модуля неизбежно, обрамляем код явными комментариями с указанием автора, задачи и даты изменения.