Что такое blue-green deployment и как выкатить обновление без даунтайма

Одна из ключевых задач при деплое backend-приложений — обновлять сервис без простоя и без влияния на пользователей. Самый простой и надёжный способ добиться этого — blue-green deployment.

Этот подход широко используется в продакшене и хорошо ложится как на классические сервера, так и на контейнерную инфраструктуру.

Что такое blue-green deployment

Blue-green deployment — это стратегия выката, при которой существует две идентичные среды:

• Blue — текущая стабильная версия приложения, обслуживающая пользователей;
• Green — новая версия приложения, развёрнутая параллельно.

В каждый момент времени трафик направлен только в одну из сред. Обновление происходит путём переключения трафика с Blue на Green.

Зачем нужен blue-green deployment

Основные цели подхода:

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

Пользователи не замечают деплой вообще — для них приложение просто продолжает работать.

Как выглядит процесс деплоя

Классический сценарий выглядит так:

1. Среда Blue обслуживает пользователей.
2. Разворачивается новая версия приложения в среде Green.
3. Проводятся smoke-тесты и health-check’и.
4. Трафик переключается на Green.
5. Blue остаётся доступной для быстрого отката.

Если после переключения обнаруживается проблема — трафик мгновенно возвращается на Blue.

Как переключается трафик

Переключение трафика может происходить разными способами:

• на уровне reverse proxy (Nginx, HAProxy);
• через load balancer;
• с помощью DNS (реже и менее надёжно).

На практике чаще всего используется reverse proxy, так как он даёт мгновенное переключение.

Пример концепции:

• app-blue → порт 8080
• app-green → порт 8081

Reverse proxy указывает, какой backend сейчас активен.

Проверка новой версии перед переключением

Перед тем как пустить пользователей в Green-среду, важно убедиться, что она работает корректно.

Обычно проверяют:

• успешный запуск приложения;
• health-check эндпоинты;
• подключение к базе данных;
• выполнение базовых сценариев.

Пока трафик не переключён, любые ошибки не затрагивают пользователей.

Rollback без боли

Главное преимущество blue-green deployment — моментальный откат.

Если после переключения:

• растёт количество ошибок;
• ломаются ключевые сценарии;
• увеличиваются задержки,

достаточно вернуть трафик обратно на старую среду.
Никаких повторных деплоев и ожиданий перезапуска сервиса.

Ограничения и подводные камни

Несмотря на простоту, у подхода есть нюансы:

Работа с базой данных

Если новая версия требует изменения схемы БД, rollback может быть сложным.
Хорошая практика — делать изменения обратно совместимыми:

• сначала добавить новые поля;
• потом переключить приложение;
• только после этого удалять старые поля.

Состояние и кэш

Если приложение хранит состояние в памяти или использует локальный кэш, переключение может привести к потере сессий.
Решение — выносить состояние во внешние хранилища (Redis, БД).

Удвоенные ресурсы

Blue-green deployment требует двух рабочих окружений, что увеличивает потребление ресурсов. Это нужно учитывать при планировании инфраструктуры.

Blue-green vs rolling update

Для понимания разницы:

• Blue-green — мгновенное переключение, простой rollback, больше ресурсов.
• Rolling update — постепенное обновление инстансов, меньше ресурсов, сложнее откатываться.

Blue-green лучше подходит для критичных сервисов, где простой недопустим.

Когда стоит использовать blue-green deployment

Подход особенно полезен, если:

• сервис имеет строгие требования к доступности;
• деплои происходят часто;
• важна возможность быстрого отката;
• инфраструктура позволяет держать две среды.

Для небольших сервисов это может быть избыточно, но для production-систем — почти стандарт.

Итоги

Blue-green deployment — простой и надёжный способ выкатывать обновления без даунтайма.

Ключевые преимущества:

• нулевой простой;
• быстрый rollback;
• предсказуемый деплой.

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