Почитывал на досуге паттерны DevOps.
Грубо говоря, переключаем балансировщик нагрузки чтобы часть пользовалей отправлялось на новую версию сервиса и собираем логи/обратную связь. В мире веб-приложений это просто. В мире 1С есть обновление структуры метаданных 
Как жить?
Канареечный релиз в 1С
Как раз неделю назад вели эксперименты с разными конструкциями на эту тематику.
косяк не в метаданных - проблема в спец-сервисах 1С на уровне сервисов
- менеджер объектных блокировок
- менеджер нумерации объектов
если бы нумерация и блокировки строилась на средствах СУБД - тогда легко можно было бы реализовать.
есть 2 костыля - как мы выкручивались
- репликатор новых сущностей - не универсальный а под функционал который нужно отпилотировать в канареечном релизе
- разделение функционала на несколько микроконфигураций которые можно быстро мигрировать и разворачивать - отсюда собственно и взялась BDD и остальная тематика.
В итоге на сегодня я сторонник потратить деньги на разделение монолитной ERP на много мелкий конфигураций и создания микрокоманд с BDD, чем на одну большую ЕБД.
P.S. Щас спрошу на партнерке - мне прям интересно что они скажут.
1 Симпатия
Вопрос актуален.
Слушай, а как по микроконфигурациям размазываете мастер-данные? Типа номенклатуры, контрагентов, складов и т.п.
если коротко - а зачем их размазывать ?
необходимо всего лишь обспечить непрерывную доступность микросервиса номенклатур, для получателей ;-).
Ну вот очень интересно было бы взглянуть как это работает 
Я всё думаю какое существующее рабочее место можно выделить в микроконфигурацию, и как-то всегда приходится много интегрировать.
1 Симпатия
Пример был бы очень полезен, для меня загадка - как можно выделить “микросервис номенклатур” например из той же erp, если номенклатура там используется в 70% а может и больше, остальных подсистем.
Если есть примеры картинки такой архитектуры из не 1с мира где то под рукой, хотелось бы посмотреть.
1 Симпатия