Deploy vs Release: почему важно понимать разницу

Вы только что закончили новую фичу на своем ноутбуке. Код работает, тесты проходят, и вы довольны результатом. Теперь нужно доставить это пользователям. Очевидный следующий шаг — выложить новую версию на продакшен-сервер. Вы запускаете скрипт деплоя, сервер начинает выполнять новый код, и вы с облегчением выдыхаете.

Но вот неудобный вопрос: действительно ли пользователи уже видят новую функциональность?

Если вы ответили «да» не задумываясь, возможно, вы смешиваете два понятия, которые стоит разделять. Деплой и релиз — это не одно и то же, и трактовать их как единое действие — значит создавать излишние риски.

Что на самом деле означает Deploy

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

Представьте это так: вы только что въехали в новую квартиру. Мебель внутри, свет горит, жить можно. Но вы еще не открыли входную дверь для гостей.

Deploy отвечает на вопрос «Находится ли новая версия на сервере?». Он не отвечает на вопрос «Пользуются ли ей пользователи?».

Что на самом деле означает Release

Release — это бизнес-решение. Это момент, когда пользователи действительно могут получить доступ к изменениям, которые вы развернули. Можно сделать deploy без release. Новая версия находится на сервере, но пользователи по-прежнему взаимодействуют со старой.

Это различие важно, потому что оно дает вам контроль. Когда вы разделяете deploy и release, вы получаете возможность независимо проверять, планировать и откатывать изменения.

Почему разделение меняет всё

Вы можете проверить до того, как увидят пользователи

Следующая диаграмма последовательности иллюстрирует разделение:

После деплоя ваша команда может убедиться, что приложение нормально работает в продакшене, не подвергая пользователей потенциальным проблемам. Вы можете запустить smoke-тесты, проверить уровень ошибок и подтвердить, что миграция базы данных ничего не сломала. Если что-то пошло не так, вы исправляете это до того, как кто-либо заметит.

Это разница между «мы задеплоили и надеемся, что работает» и «мы задеплоили, проверили, что работает, и затем решили показать пользователям».

Вы контролируете, когда изменения попадают к пользователям

Возможно, вы хотите сделать релиз в часы низкой нагрузки. Возможно, вашей маркетинговой команде нужно время на подготовку анонса. Или вы ждете, пока будет готова документация. При разделении deploy и release вы можете запланировать релиз независимо от деплоя.

Это особенно полезно для изменений, чувствительных ко времени. Вы можете немедленно задеплоить патч безопасности на продакшен-серверы, а затем выпустить его пользователям в тщательно выбранный момент.

Откат становится безопаснее

Rollback — это действие по возврату приложения к предыдущей версии. Когда deploy и release связаны, откат работает по принципу «все или ничего». Вы откатываете код, и пользователи сразу видят старую версию.

Когда они разделены, у вас есть варианты. Если релиз вызывает проблемы, вы можете откатить релиз без повторного деплоя старой версии. Новый код остается на сервере, но пользователи видят старое поведение. Альтернативно, вы можете откатить деплой, и релиз последует автоматически.

Такая гибкость снижает давление на команду. Вам не нужно спешить с исправлением, потому что вы можете быстро скрыть проблемное изменение от пользователей.

Как разделить Deploy и Release на практике

Самый простой подход — feature toggles (флаги функций). Вы деплоите новый код с выключенной фичей через конфигурацию. Когда команда готова, вы переключаете флаг. Этот переключатель и есть момент вашего релиза.

Другой подход — маршрутизация трафика. Задеплойте новую версию на подмножество серверов, затем постепенно направляйте пользователей на новую версию. Это распространено в canary-развертываниях и blue-green-развертываниях. Деплой происходит, когда новая версия оказывается на серверах. Релиз происходит постепенно по мере переключения трафика.

Некоторые команды используют разделение сред. Деплой на стейджинг, который зеркалирует продакшен, проверка там, затем деплой на продакшен и немедленный релиз. Это все равно разделяет deploy и release, если рассматривать деплой на стейджинг как этап верификации перед продакшен-релизом.

Распространенные заблуждения

«В нашей системе deploy и release — это одно и то же». Обычно это означает, что вы никогда их не разделяли, а не то, что они по своей сути одинаковы. Если ваш деплой автоматически делает фичу доступной всем пользователям, вы связали их по своему выбору, а не по необходимости.

«Feature toggles добавляют сложности». Да, но эта сложность управляема. Начните с простых булевых флагов в конфигурационных файлах. Вам не нужна полноценная система флагов функций с первого дня.

«Разделение замедляет нас». На первых порах — да. Но в первый раз, когда вы поймаете проблему в продакшене до того, как ее увидят пользователи, или в первый раз, когда вы откатите релиз за секунды вместо минут, вы увидите ценность.

Короткий практический чеклист

Перед следующим деплоем задайте себе эти вопросы:

• Как мы проверим, что новая версия работает в продакшене после деплоя?
• Что является триггером для релиза? Время? Ручное утверждение? Автоматическая проверка здоровья?
• Если релиз вызывает проблемы, как мы скроем его от пользователей без повторного деплоя?
• Кто принимает решение о релизе? Инженерия? Продукт? Оба?
• Можем ли мы сделать deploy без релиза? Если нет, какое минимальное изменение позволит это сделать?

Главный вывод

Deploy и release — это два разных момента в процессе доставки. Deploy — технический: код на сервере. Release — бизнесовый: пользователи могут использовать код. Их разделение дает вам время на проверку, гибкость в планировании и более безопасные откаты.

Вам не нужны сложные инструменты для начала. Простого конфигурационного флага или ручного переключателя трафика достаточно. Важно осознать, что это два разных решения, а не одно. Как только вы начнете относиться к ним раздельно, вы удивитесь, почему раньше считали их одним и тем же.

И это различие становится еще более важным по мере того, как вы начинаете деплоить чаще. Потому что после первого релиза ваше приложение будет продолжать меняться. Каждое изменение снова проходит через деплой и релиз. Понимание разницы на раннем этапе делает эти повторяющиеся циклы более безопасными и менее стрессовыми.