← На главную
При сопровождении сильно доработанных конфигураций 1С, особенно таких масштабных решений, как 1С:Управление торговлей 11, регулярное обновление становится нетривиальной задачей. Ситуация усложняется во много раз, если информационная база подключена к хранилищу конфигурации, а перепрыгнуть требуется сразу через десяток релизов. Рассмотрим ключевые проблемы, с которыми сталкивается разработчик в такой ситуации, и разберем по шагам правильную технологию обновления.
Ограничения платформы при работе с хранилищем конфигурации
Проанализируем технические ограничения, заложенные в платформу 1С:Предприятие 8.3:
- Блокировка полной загрузки конфигурации. Когда база подключена к хранилищу, пункт меню «Конфигурация — Загрузить конфигурацию из файла» аппаратно заблокирован. Мы не можем просто подготовить итоговый файл
.cf в копии и загрузить его целиком в подключенную базу.
- Проблема простого сравнения и объединения. Если попытаться применить обновление через «Конфигурация — Сравнить, объединить с конфигурацией из файла», то изменения в метаданных и коде будут перенесены, но версия конфигурации поставщика не изменится. В результате конфигурация потеряет корректную связь с поддержкой вендора, а последующие обновления станут некорректными.
- Раздувание файла хранилища и риск сбоев. Если выполнять каждый из 10 промежуточных шагов обновления непосредственно внутри подключенной базы с фиксацией каждого релиза, файл хранилища
1Cv8ddb.1cd стремительно раздуется. Длительные коммиты больших объемов метаданных чреваты сетевыми сбоями, повреждением базы хранилища и полной блокировкой работы коллег по разработке.
- Особенности захвата объектов. При выполнении штатного обновления через механизм поддержки обязательно требуется рекурсивный захват всех подчиненных объектов. Если захватить только корень конфигурации, платформа обновит только его свойства, а все измененные поставщиком дочерние объекты останутся нетронутыми.
Оптимальный порядок действий: двухэтапное обновление с сохранением хранилища
Для того чтобы не перегружать хранилище лишними промежуточными версиями, не потерять историю разработки и гарантированно обновить конфигурацию поставщика, применим проверенную двухэтапную методику.
Этап 1. Подготовка конфигураций в автономной базе
Разберем подготовительный этап, который мы проводим полностью автономно, в отдельной базе без подключения к хранилищу:
- Создаем отдельную копию базы или берем чистую базу на исходном релизе поставщика.
- Выполняем последовательное обновление по цепочке релизов, проводя трехстороннее объединение и адаптируя нетиповые доработки.
- Обязательно учитываем ограничения Библиотеки стандартных подсистем (БСП) и технологической платформы. При переходе через большое количество релизов нельзя накатывать изменения в рабочую БД «одним махом», если не отработали обязательные и отложенные обработчики данных БСП. Определяем узловые релизы, запускаем режим «1С:Предприятие» для миграции структуры данных и регистров.
- На выходе формируем два файла:
— Типовой файл поставщика целевого релиза (сохраняем через «Конфигурация — Поддержка — Настройка поддержки — Сохранить в файл»).
— Итоговый адаптированный файл конфигурации (выгружаем через «Конфигурация — Сохранить конфигурацию в файл»).
Этап 2. Внедрение изменений в хранилище в два прохода
Теперь перейдем к подключенной базе. Разберем по шагам, как корректно обновить конфигурацию поставщика и накатить доработки единой версией:
- В базе, подключенной к хранилищу, выполняем рекурсивный захват всех объектов, начиная с самого корня метаданных.
- Проход 1: Обновление конфигурации поставщика. Вызываем команду «Конфигурация — Поддержка — Обновить конфигурацию» и указываем подготовленный типовой файл поставщика финального релиза. В открывшемся окне сравнения и объединения снимаем все флажки абсолютно со всех объектов и нажимаем кнопку «Выполнить». В результате платформа обновляет конфигурацию поставщика до актуального релиза, оставляя рабочую конфигурацию нетронутой.
- Проход 2: Накат адаптированных доработок. Выполняем команду «Конфигурация — Сравнить, объединить с конфигурацией из файла», выбрав итоговый адаптированный
.cf. Применяем все изменения модулей, форм и структуры метаданных.
- Проверяем работоспособность конфигурации, применяем изменения к базе данных и помещаем все захваченные объекты в хранилище единой версией (одним коммитом).
Альтернативный вариант: создание нового хранилища
Рассмотрим ситуацию, когда выполняется переход между глобальными редакциями (например, при масштабном переходе между ветками конфигурации) или когда текущее хранилище сильно повреждено либо перегружено старыми версиями. В таком случае отключаем конфигурацию от старого хранилища, выполняем полную загрузку подготовленной конфигурации через «Конфигурация — Загрузить конфигурацию из файла» и создаем совершенно новое хранилище. Однако помним, что этот метод приводит к утрате истории версий в рамках одного репозитория и требует согласования с заказчиком или командой разработки.