EN
Кейс

Релизный контур на форке Unleash

Форк Unleash, который стал релизным контуром банка: семь команд в начале, около пятидесяти в конце.

Что изменилось
2,4% → 0,9%
change failure rate
10 → 5 дней
time-to-market
×4
частота релизов
~50
продуктовых команд
Задача

Unleash из коробки закрывает переключение флагов и постепенные выкаты. Дальше начинается то, чего в коробке нет: кто имеет право трогать флаг в проде, как описать сегмент сложнее «десять процентов пользователей» и что делать команде, которая не хочет писать поллинг и кеширование заново в каждом сервисе. Из последнего вопроса и вырос свой SDK.

Что построено
Ролевая модель доступа: право переключить флаг в проде отделено от права его завести.
Динамические сегменты: правило выката описывается атрибутами вместо списка идентификаторов.
Свой SDK поверх клиента Unleash: поллинг, кеш и деградация до последнего известного значения написаны один раз, а не в каждом сервисе.
Как разошлось по командам

Технически там было сложно не все. Сложно было договориться. Первые семь команд пришли сами: им нужны были постепенные выкатки. Остальные подтянулись, когда пайплайн начал спрашивать, почему изменение едет без флага, а дашборд DORA показал, у кого change failure rate выше соседского.

Портал разработчика

Сверху встал Backstage: каталог сервисов, статус CI/CD и витрина DORA в одном месте. Руководство перестало просить отчеты и начало открывать дашборд. В этом и был смысл. Онбординг нового инженера сократился примерно до двух рабочих дней.

Что сделал бы иначе

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

Стек
TypeScriptNode.jsReactUnleashBackstageCI/CDDORA