Отдельно рассмотрим вариант с 4️⃣ стендами.

Он может применяться, когда по внутренним регламентам или соображениям безопастности мы сознательно отказываемся от Continuous Deployment на прод. Мы изобрели этот гибридный подход, чтобы оставить нашему единорожку возможность бесшовно эволюционировать
🐴🔜🦄 и, в то же время, иметь возможность выпускать его на волю дискретными релизами.

Какая проблема возникает при отказе от Continuous Deployment? То, что нам приходится где-то замораживать версию продукта для стабилизации, но при этом мы не хотим останавливать разработку нового функционала. Поэтому можно использовать следующий поход:
sandbox и test остаются как и в предыдущем варианте — это инкубатор, где единорог постепенно эволюционирует.

Как только мы понимаем, что он достаточно хорош, нам приходится его клонировать, отсаживая в отдельный загончик — релизную ветку. Оттуда собираются артефакты на третий промежуточный стенд — stage. На нем происходит стабилизация, после чего единорожка выпускается на волю (на prod), а релизная ветка со всеми багфиксами тэгается, мерджится обратно в транк и закрывается. При этом основную ветку ничто не останавливает и она уходит вперед.

🐛 Если находится критический баг на продакшене, мы можем выпустить патч-релиз. Для этого мы просто восстанавливаем релизную ветку нужного сервиса из тэга и используем stage для новых изменений в нашем загончике, после чего он снова попадает на prod, а изменения тэгаются, мержатся в основную ветку, а патч-ветка закрывается.

При таком подходе мы все еще остаемся в парадигме Trunk Based Development, т.к. у нас
- одна основная ветка (trunk), 🦋
- короткоживущие фича ветки для эволюции (slfb),
- релизные ветки, которые живут только в период стабилизации,
- стабилизационные багфикс ветки, которые живут еще меньше, чем релизная

#rdclr_backend #rdclr_frontend #product