Как организовать тестирование и поэтапное внедрение доработок в РИБ 1С:Розница на большую сеть магазинов

← На главную

При сопровождении крупной торговой сети (50 и более магазинов), работающей в распределенной информационной базе (РИБ), часто возникает необходимость оперативно вносить изменения в кассовую линейку: подключать отправку SMS, интегрировать новые программы лояльности, корректировать интерфейс рабочего места кассира (РМК). Главная сложность заключается в том, что применение новой конфигурации в центральной базе (ЦБ) автоматически регистрирует изменения метаданных для всех периферийных узлов. В результате регулярный обмен данными приостанавливается до тех пор, пока на каждой кассе не будет выполнено обновление конфигурации базы данных. Разберем основные подходы, позволяющие тестировать и безопасно раскатывать функционал на пилотных магазинах без сбоев в работе всей сети.

Вариант 1. Использование расширений конфигурации (.cfe)

Рассмотрим наиболее современный и безопасный способ изоляции кассовых доработок. Вместо изменения основной конфигурации в ЦБ вся новая функциональность (кнопки в РМК, интеграции с внешними веб-сервисами, алгоритмы начисления бонусов) реализуется в виде отдельного расширения.

Разберем по шагам преимущества и логику такого подхода:

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

Вариант 2. Механизм Feature Flags (переключатели функционала) через справочник или функциональные опции

Проанализируем ситуацию, когда доработку невозможно вынести в расширение и код уже внедрен в основную конфигурацию. Чтобы код выполнялся только в определенных торговых точках, используется архитектурный паттерн Feature Flags (фич-тогглы).

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

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

Посмотрим на пример программной проверки в коде:


Если МодульУправленияФлагами.ФичаАктивна("ПроверкаБонусовОнлайн", ТекущийМагазин) Тогда
    ВыполнитьЗапросКСервисуБонусов();
Иначе
    ВыполнитьСтандартныйРасчетСкидок();
КонецЕсли;

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

Вариант 3. Программное управление регистрацией изменений конфигурации в РИБ

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

Разберем по шагам, как отправить обновление конфигурации только на пилотные кассы:

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

Посмотрим на пример кода:


ВыборкаУзлов = ПланыОбмена.ПоМагазинам.Выбрать();
Пока ВыборкаУзлов.Следующий() Цикл
    УзелОбъекта = ВыборкаУзлов.ПолучитьОбъект();
    Если Не УзелОбъекта.ЭтоПилотныйМагазин Тогда
        ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбъекта.Ссылка, Метаданные.Конфигурация);
    КонецЕсли;
КонецЦикла;

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

Вариант 4. Архитектурное разделение контуров обмена

Если специфика бизнеса требует постоянных доработок и кастомизации под разные форматы магазинов, рассмотрим вариант с выделением нескольких контуров обмена:

Создается промежуточная база (например, узел для пилотных магазинов) и основной узел для стабильной сети.
Все изменения сначала накатываются и тестируются на выделенном пилотном узле с 3–5 магазинами.
Данные о продажах консолидируются в головной учетной системе (например, 1С:Управление торговлей или 1С:ERP) через универсальный формат обмена EnterpriseData, который не зависит от совпадения конфигураций баз на уровне метаданных.