Канареечный релиз в 1С


#1

Почитывал на досуге паттерны DevOps.


Грубо говоря, переключаем балансировщик нагрузки чтобы часть пользовалей отправлялось на новую версию сервиса и собираем логи/обратную связь. В мире веб-приложений это просто. В мире 1С есть обновление структуры метаданных :frowning:
Как жить?


#2

Как раз неделю назад вели эксперименты с разными конструкциями на эту тематику.

косяк не в метаданных - проблема в спец-сервисах 1С на уровне сервисов

  • менеджер объектных блокировок
  • менеджер нумерации объектов

если бы нумерация и блокировки строилась на средствах СУБД - тогда легко можно было бы реализовать.

есть 2 костыля - как мы выкручивались

  • репликатор новых сущностей - не универсальный а под функционал который нужно отпилотировать в канареечном релизе
  • разделение функционала на несколько микроконфигураций которые можно быстро мигрировать и разворачивать - отсюда собственно и взялась BDD и остальная тематика.

В итоге на сегодня я сторонник потратить деньги на разделение монолитной ERP на много мелкий конфигураций и создания микрокоманд с BDD, чем на одну большую ЕБД.

P.S. Щас спрошу на партнерке - мне прям интересно что они скажут.


#3

Вопрос актуален.
Слушай, а как по микроконфигурациям размазываете мастер-данные? Типа номенклатуры, контрагентов, складов и т.п.


#4

если коротко - а зачем их размазывать ?

необходимо всего лишь обспечить непрерывную доступность микросервиса номенклатур, для получателей ;-).


#5

Ну вот очень интересно было бы взглянуть как это работает :slight_smile:

Я всё думаю какое существующее рабочее место можно выделить в микроконфигурацию, и как-то всегда приходится много интегрировать.


#6

Пример был бы очень полезен, для меня загадка - как можно выделить “микросервис номенклатур” например из той же erp, если номенклатура там используется в 70% а может и больше, остальных подсистем.
Если есть примеры картинки такой архитектуры из не 1с мира где то под рукой, хотелось бы посмотреть.