🚀 Код уже на проде, а пользователи его не видят? Это не bug!

Продолжу тему про релизы (начало тут). И напомню, что возникла она от нашего с Темой Пулявиным "батла" на рупоре и кейсовой задачки (видео).

Очень часто путают два понятия:
🔹 Деплой — это когда код выкатывается на продакшн. Он там есть, но выключен, пользователи его не видят.
🔹 Релиз — это момент, когда фича включается и становится доступна клиентам.

Почему классно разводить деплой и релиз:
– можно заранее проверить, что код живет на проде и ничего не ломает;
– баги отлавливаются безопаснее;
– релиз можно делать в удобное время (например, днем, а не в 3 ночи, когда нагрузка спала).

👨‍💻 У меня дома это прямо отдельная философия: муж много лет работает в процессинговых и интеграционных платформах, и там без такого подхода никак. Как только меняешь один кусок, задеваешь кучу функционала. Разделение деплоя и релиза спасает: выкатываешь код, проверяешь, а включаешь только тогда, когда уверен.

Когда помогает:
– быстрые гипотезы: включили на 1% пользователей, посмотрели метрики;
– highload-кейсы: можно откатывать или переключать группы;
– сокращение времени реакции на инциденты.

Когда не получится:
– если бизнес не готов к тому, что «фича на проде, но выключена».

🚨 Важно: Такой подход требует пересмотра архитектуры и инженерных практик. И его лучше закладывать заранее (да, это уже про бережливое проектирование), а не прикручивать потом.

Техники, которые помогают:
– Feature toggles (фичефлаги)
– Blue-green deployment
– Canary releases
– Trunk-based development

📎 Полезные материалы:
– Martin Fowler про Feature Toggles (одна из самых подробных и развернутых справок)
– Trunk Based Development
– Видео: На пути к TBD: как мы внедряли feature flags
– Видео: From Development to Deployment

💬 А вы видите минусы в разведении деплоя и релиза?