🟢 Стратегии деплоя

Деплой (deployment) / развертывание — процесс доставки новой версии приложения в продакшн и её ввода в эксплуатацию.

Стратегия деплоя определяет
- как именно новая версия попадает в прод,
- какая часть пользователей её увидит
- что произойдёт в случае ошибки


🔵 Big Bang / Replace/ Recreate Deployment (полная замена)

Как работает

1. Старая версия приложения полностью останавливается
2. Обновляется код и конфигурации
3. Запуск новой версии

Плюсы и минусы

➕ просто реализовать
➕ минимальные требования к инфраструктуре

➖ длительный простой
➖ изменения затрагивают пользователей полностью
➖ откат требует повторного деплоя старой версии

Где применяется

🔹 внутренние системы, где простой допустим
🔹 низкокритичные сервисы
🔹 редкие релизы
🔹 на ранних этапах проекта / в условиях ограниченных ресурсов


🟢 Rolling Deployment (постепенное обновление)

Как работает

- новая версия разворачивается постепенно, по экземплярам (ноды, поды, контейнеры) приложения
- балансировщик исключает обновляемые узлы из трафика
- без полной остановки сервиса


➕ нет полного простоя
➕ не требует дублирования окружений

➖ старая и новая версии работают одновременно (получение неактуальных данных)
➖ требуется обратная совместимость
➖ откат происходит постепенно, занимает время

Где применяется

🔹 микросервисная архитектура
🔹контейнеризированные приложения (Kubernetes, облачные платформы)


🔵 Blue-Green Deployment (Сине-зеленое развертывание)

Используются идентичные production-окружения:
- Blue — текущая версия
- Green — новая версия

Процесс деплоя:

1. Разворачивание новой версии в Green
2. Проверка работоспособности
3. Переключение всего трафика с Blue на Green
4. Среда Blue становится standby

➕ мгновенный откат. При обнаружении проблем после переключения трафик возвращается на Blue
➕ нет простоя. Релиз — перенаправление трафика
➕ чёткий контроль версии. Новую версию можно проверить в проде под реальной нагрузкой перед переключением

➖ удвоенные ресурсы
➖ сложность работы с БД , кэшами, файловыми хранилищами, чтобы обе версии могли работать с общим состоянием или его миграция была управляемой

Где применяется

🔹критичные пользовательские системы
🔹сервисы с высокими SLA


🟢 Canary Release (канареечное развертывание)

- новая версия выкатывается на небольшую часть пользователей
- доля увеличивается поэтапно

Применяется для высоконагруженных / критически важных приложений

➕ минимизация рисков
➕ раннее обнаружение проблем

➖ сложность настройки
➖ повышенные требования к наблюдаемости


🔵 Shadow Deployment (теневое развертывание)

- новая версия развертывается параллельно со старой
- пользовательские запросы дублируются и отправляются в новую версию, но ответы от новой версии игнорируются

Применение

Тестирование новой версии под реальной нагрузкой, но без риска для пользователей
После анализа логов и метрик теневой версии выбирается одна из стратегий (Blue-Green, Canary)


👉 Feature Toggles (флаги)

Это не стратегия деплоя, а техника, которая усиливает другие стратегии

Новая функциональность «завернута» в оператор (флаг), который можно включать/выключать без деплоя (также только для группы пользователей)


👉 A/B-тестирование

Цель — не безопасный деплой, а валидация бизнес-гипотез (какой вариант интерфейса дает большую конверсию)
Часто это следующий шаг после успешного Canary-релиза, когда нужно принять решение оставить новую версию или откатить


📎 Материалы

1. Стратегии деплоя в Kubernetes
2. Стратегии развертывания (деплоя) и стратегии кэширования
3. 6 способов деплоя веб-приложений
4. Deploy (деплой)
5. Стратегии деплоя: как мы пришли к использованию Argo CD

📚 Книги
1. Грокаем Continuous Delivery - У. Кристи
2. Continuous delivery. Практика непрерывных апдейтов - Э.Вольф
3. Руководство по DevOps - Д. Ким, П. Дебус, Д.Уиллис, Д.Хамбл С.Д.

#инфраструктура

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу