← На главную

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

Отработают ли обработчики обновления БСП при переходе через релиз

Рассмотрим механику работы подсистемы обновления версии программы из Библиотеки стандартных подсистем (БСП). При обновлении конфигурации сразу на несколько релизов (например, с версии 3.0.52 сразу на 3.0.57) подсистема БСП ведет себя следующим образом:

1. Фиксация текущей версии: В информационной базе в специальном регистре сведений ВерсииПодсистем хранится номер релиза, который был установлен до обновления.
2. Построение дерева обработчиков: При первом запуске базы в режиме «1С:Предприятие» БСП считывает текущий номер версии из метаданных и сопоставляет его с номером из регистра. Программа автоматически формирует последовательный список всех обязательных и отложенных процедур обновления для всех пропущенных промежуточных релизов.
3. Последовательное выполнение: Все зарегистрированные обработчики обновления выполняются строго по цепочке от старых версий к новым. Пропуск обработчиков промежуточных релизов платформой не допускается.

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

Особенности обновления конфигурации поставщика в хранилище

Выясним, как платформа 1С синхронизирует конфигурацию поставщика при использовании хранилища конфигурации:

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

Почему не следует подключать рабочую базу напрямую к хранилищу

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

1. Риск повреждения кэша и блокировок: Прямое получение объектов из хранилища в рабочей базе увеличивает вероятность блокировок служебных таблиц и сбоев локального кэша конфигуратора.
2. Человеческий фактор: Случайный захват объекта или динамическое обновление в рабочей базе, подключенной к хранилищу, может привести к рассинхронизации метаданных и повреждению структуры информационной базы.
3. Разрастание файла хранилища: Хранение множества версий тяжелых конфигураций поставщика внутри файла базы хранилища (1cv8ddb.1cd) приводит к его раздуванию и деградации производительности. Хранилище требует периодического сжатия через меню Хранилище конфигурации — Администрирование хранилища — Сократить.

Рекомендуемая схема доставки обновлений (Best Practice)

Разберем по шагам правильный технологический процесс обновления и поставки изменений:

1. Обновление в базе разработки: В отдельной базе для разработки, подключенной к хранилищу, захватываем корень конфигурации и выполняем обновление на целевой релиз поставщика с объединением наших доработок.
2. Фиксация версии: Применяем изменения структуры базы данных (клавиша F7), проверяем синтаксическим контролем и помещаем обновленную конфигурацию в хранилище.
3. Выгрузка файла конфигурации: Из базы разработки или специального сборочного контура выгружаем полный файл конфигурации (.cf).
4. Тестирование на копии: Загружаем полученный .cf в тестовую копию рабочей базы. Запускаем режим «1С:Предприятие», дожидаемся полного завершения фоновых и регламентных процедур обновления БСП (контролируется через форму Результаты обновления программы).
5. Обновление рабочей базы: После успешного тестирования накатываем выгруженный .cf файл на рабочую базу в монопольном режиме через сравнение/объединение конфигураций либо пакетный запуск конфигуратора.

Альтернативные подходы к архитектуре обновлений

Проанализируем современные варианты оптимизации процесса обновлений:

1. Перевод доработок в расширения (.cfe): Максимальный перенос доработок прикладного решения в механизм расширений позволяет вернуть основную конфигурацию на полную поддержку вендора. В этом случае типовая база обновляется стандартными файлами .cfu в штатном режиме, а хранилище используется исключительно для разработки расширений.
2. Создание собственной поставки: Для сложных тиражируемых решений создается собственная конфигурация поставщика поверх типовой. Рабочие базы ставятся на поддержку собственной поставки и обновляются собственными файлами обновлений (.cfu), в том числе в автоматическом режиме через командную строку.