Стратегии деплоя
Деплой (deployment) / развертывание — процесс доставки новой версии приложения в рабочее окружение (production) и её ввода в эксплуатацию.
Затрагивает:
- доступность системы для пользователей,
- целостность данных,
- стабильность интеграций,
- выполнение SLA.
Без продуманной стратегии деплой несёт риски:
- простой системы,
- массовые ошибки у пользователей,
- невозможность быстрого отката,
- финансовые и репутационные потери.
Стратегия деплоя определяет как именно новая версия попадает в прод, какая часть пользователей её увидит и что произойдёт в случае ошибки.
Фундаментальные стратегии
Big Bang / Replace/ Recreate Deployment (Полная замена)
Старая версия приложения полностью останавливается, после чего разворачивается новая.
Как работает
- Остановка приложения,
- Обновление кода и конфигурации,
- Запуск новой версии.
Плюсы и минусы
- Простота реализации.
- Минимальные требования к инфраструктуре.
- Длительный простой,
- Пользователи полностью затронуты изменениями,
- Откат требует повторного деплоя старой версии.
Где применяется
- Внутренние системы, где простой допустим,
- Низкокритичные сервисы,
- Редкие релизы,
- На ранних этапах проекта или в условиях ограниченных ресурсов.
Когда неприменима
- Пользовательские сервисы,
- Системы с SLA по доступности.
Rolling Deployment (Постепенное обновление)
Новая версия разворачивается постепенно, по экземплярам (ноды, pod’ы, контейнеры) приложения, без полной остановки сервиса.
Как работает
- Экземпляры обновляются по очереди,
- Балансировщик исключает обновляемые узлы из трафика.
Плюсы и минусы
- Нет полного простоя
- Не требует дублирования окружений
- Старая и новая версии работают одновременно (получение неактуальных данных)
- Требуется обратная совместимость
- Откат происходит постепенно и занимает время
Где применяется
- Микросервисная архитектура
- Контейнеризированные приложения (Kubernetes, облачные платформы).
Стратегии с продвинутым управлением трафиком
Blue-Green Deployment (Сине-зеленое развертывание)
Используются два идентичных production-окружения:
- Blue — текущая версия
- Green — новая версия.
Трафик переключается между ними целиком.
Процесс деплоя
- Разворачивание новой версии в Green
- Проверка работоспособности
- Переключение трафика с Blue на Green (часто через настройку балансировщика нагрузки или маршрутизатора)
- Прежняя среда Blue становится standby
Плюсы и минусы
- Мгновенный откат. При обнаружении проблем после переключения трафик возвращается на Blue
- Отсутствие простоя. Релиз — перенаправление трафика
- Чёткий контр оль версии. Новую версию можно проверить в production-окружении под реалистичной нагрузкой перед переключением
- Удвоенные ресурсы
- Сложность работы с БД , кэшами, файловыми хранилищами, чтобы обе версии могли работать с общим состоянием или его миграция была управляемой
Где применяется
- Критичные пользовательские системы
- Сервисы с высокими SLA
Canary Release (Канареечное развертывание)
Новая версия выкатывается на небольшую часть пользователей. Распределение трафика:
- Часть пользователей направляется на новую версию.
- Доля увеличивается поэтапно.
- Если есть проблемы, новая версия откатывается, а страдает малая часть аудитории.
Важно наличие
- продвинутого инструмента для маршрутизации трафика (сервисная сеть, у мные балансировщики),
- мониторинга метрик: ошибки, задержки, бизнес-показатели.
Отличие от Blue-Green
- Частичный, а не полный переход.
- Управление трафиком, а не окружениями.
Где применяется
Для высоконагруженных или критически важных приложений, где риск даже для 1% пользователей должен быть минимизирован.
Гибридные и специфические стратегии
Feature Toggles (Flags) как основа стратегий
Это не стратегия деплоя, а техника, которая усиливает другие стратегии. Деплой ≠ релиз.
Новая функциональность «завернута» в оператор (флаг), который можно включать/выключать без деплоя.
Код можно выкатить через Blue-Green или Canary, но функция останется выключенной для всех. Можно включить для определенной группы пользователей (по сути, провести Canary-релиз на уровне функциональности).
Риски:
- Рост технического долга.
- Усложнение логики кода.
A/B-тестирование как стратегия деплоя
Цель — не безопасный деплой, а валидация бизнес-гипотез (какой вариант интерфейса дает большую конверсию). Технически реализуется аналогично Canary, с тонким контролем аудитории.
Часто является следующим шагом после успешного Canary-релиза, когда нужно принять решение оставить новую версию или откатить.
Shadow Deployment (Теневое развертывание)
Новая версия развертывается параллельно со старой. Пользовательские запросы дублируются и отправляются в новую версию, но ответы от новой версии игнорируются.
Зачем применяется
Нагрузочное тестирование новой версии под реальной нагрузкой, но без риска для пользователей. После анализа логов и метрик «теневой» версии выбирается одна из активных стратегий (Blue-Green, Canary)
Ограничения
- Не выявляет UX-проблемы.
- Увеличивает нагрузку на систему.
Критерии выбора стратегии
Выбор зависит от контекста проекта:
- критичности системы;
- допустимого простоя;
- архитектуры приложения;
- DevOps и мониторинга.
Ключевые факторы для принятия решения:
| Фактор | Рекомендация |
|---|---|
| Требования к доступности (SLA) | При нулевом допуске на простой — только Blue-Green, Canary или их комбинации с Feature Flags. |
| Допустимое время простоя | Если простой допустим, можно рассмотреть Rolling. Если нет — Blue-Green/Canary. |
| Сложность отката | Если откат долгий и сложный, Blue-Green дает мгновенное решение. |
| Бюджет на инфраструктуру | Blue-Green требует значительных ресурсов. Canary и Rolling более экономны. |
| Зрелость процессов | Для Canary и Feature Flags необходимы продвинутые инструменты маршрутизации, мониторинг и культура data-driven решений. |
Типовые ошибки
- Использование сложных стратегий без необходимости.
- Отсутствие плана отката.
- Игнорирование мониторинга.
Материалы
- Стратегии деплоя в Kubernetes: rolling, recreate, blue/green, canary, dark (A/B-тестирование)
- Стратегии развертывания (деплоя) и стратегии кэширования
- 6 способов деплоя веб-приложений
- Deploy (деплой)
- Стратегии деплоя: как мы пришли к использованию Argo CD
- Лучшие практики для деплоя высокодоступных приложений в Kubernetes. Часть 1
- Лучшие практики для деплоя высокодоступных приложений в Kubernetes. Часть 2
- Разработка, деплой, эксплуатация: как перестать терять ценность на пути к продакшену
- Blue-green deployment, canary release: рецепт приготовления безрисковых релизов
- Как использовать blue-green-деплой: руководство по выкату одного и нескольких приложений
- Blue-Green и Canary деплойменты в микросервисах
- Канареечное развертывание и его роль в DevOps
- Простой и безопасный способ автоматизации канареечных деплоев с помощью Helm
- Как мы делаем канареечный деплой в PaaS
- Топ 8 стратегий развертывания Kubernetes: преимущества и варианты использования
- Что такое feature toggle или как избавиться от мучительных мёржей и долгоживущих веток?
- Изолируем микросервисы с помощью Feature toggles в ASP.NET Core. Практика
- «Обновляй меня нежно» — как мы докатились до Feature Toggle
- Кастомизируем xUnit: feature-toggles или API тесты не для всех (конечных точек)
- Переключатели функциональности (feature toggles): виды, преимущества и работа с ними в .NET
- Feature Toggles и их применение. История одного проекта
- Разбираемся с Feature Toggle на примере Unleash
Видео
- Стратегии деплоя в Kubernetes
- Деплой веб-приложения на практическом примере. Проще, чем кажется
- 7.1-kubernetes. Деплоим без даунтайма с rolling update. Kubernetes на русском
- Rolling Updates: как обновлять без простоев и стресса
- Что такое BLUE-GREEN ДЕПЛОЙМЕНТ за 8 минут
- Blue-Green Deploy в Docker Compose или как обновлять приложения без простоя
- Blue-Green Deployment на минималках
- Deployment Strategies Explained: Blue-Green vs. Canary vs. Rolling
- Канареечный деплой | Антон Малафеев | PaaS Meetup 2023 | СберМаркет Tech