ПЕРВЫЙ ВИД
Canary Deployment
(Канареечный деплой)
Назван по аналогии с "канарейками в шахтах", по реакции которых шахтеры оценивали безопасность шахт. В современных реалиях птичками становится небольшая группа пользователей, которая первой взаимодействует с новой версией. Обычно выкатывается на 1-5% трафика, затем, если всё стабильно, — идет расширение: 10%, 25%, 50%, 100%. Весь процесс контролируется по метрикам: ошибки, латентность, бизнес-показатели (например, конверсии)
- Контролируемый риск: баги влияют на ограниченное число пользователей
- Гибкость: можно медленно масштабировать rollout, давая больше времени на оценку
- Аналитика и A/B тесты: канареек на проде может быть несколько , что позволяет собирать поведенческие данные и проводить тесты
- Быстрый откат: достаточно выключить канареечный сегмент
- Сложная маршрутизация трафика: нужен продвинутый механизм маршрутизации на уровне балансировщика нагрузки, API Gateway, ingress controller и т.д.
- Две версии одновременно: увеличивает затрату ресурсов на мониторинг, логирование и дебага
- Сложности с совместимостью данных: если новая версия использует требует изменение в схеме данных — нужен продуманный backward-совместимый подход
✔️Продукты с большим числом пользователей и частыми релизами
✔️Критичные бизнес-функции, где важно протестировать поведение на реальных данных
✔️Развёртывания с продвинутой системой мониторинга (Prometheus, NewRelic, Datadog)
ВТОРОЙ ВИД
Blue-Green Deployment
В рамках этого подхода поддерживаются две идентичные среды: например Blue (текущая, продакшн) и Green (новая). Green разворачивается и тестируется в фоне. Когда готова — трафик плавно переключается на неё (через DNS, LB, ingress). Если возникли проблемы — откат осуществляется моментальным возвратом на Blue
- Мгновенный rollback: просто переключение обратно
- Изоляция версий: Blue и Green полностью независимы (избегается смешение)
- Чистота среды: новая версия тестируется в production-like окружении до релиза
- Запас по мощности: в случае резкого роста нагрузки Blue и Green объединяются и система способна держать до 2х нагрузки
- Большой расход ресурсов: нужно поддерживать одновременно 2 полноценные копии приложения (а иногда и баз данных)
- Сложности с миграциями БД: как управлять изменениями схемы, если обе версии используют одну и ту же БД?
✔️Когда важна предсказуемость и атомарность деплоя
✔️В системах, где легче задублировать окружение, чем поддерживать сложную логику маршрутизации
✔️Когда релизов немного, но они крупные и требуют подготовки
ТРЕТИЙ ВИД
Rolling Deployment
Приложение обновляется постепенно, по одной или группе нод.
Обычно происходит так:
1. Остановка одного экземпляра старой версии
2. Развёртывание новой версии на этом инстансе
3. Проверка здоровья
4. Переход к следующему
- Нет простоев: хотя бы часть экземпляров всегда обслуживает запросы
- Низкое потребление ресурсов: не нужно дублировать окружение
- Легко автоматизируется в современных платформах
- Сложный откат: приходится откатывать каждый экземпляр, возможно вручную
- Уменьшение запаса нагрузки: если число инстансов или подов приложения лимитировано, то при остановки экземпляров старой версии трафик распределяется на оставшиеся экземпляры, что может приводить к увеличению вероятности отказа
- Увеличенное время отката: чем больше инстансов тем больше потенциальное время отката и даунтайма
✔️В облачной или контейнерной инфраструктуре, где автоматизация важнее изоляции
✔️При высокочастотных, неопасных обновлениях (например, UI, мелкие фичи)
✔️В микросервисных архитектурах, где каждая служба обновляется отдельно
ЧЕТВЕРТЫЙ ВИД
Деплой имени “Ковбоя Билла”
В рамках этого подхода код без предупреждения правится прямо на проде и в дальнейшем раскидывается через scp минуя репозиторий. Версионность не поддерживаются, мониторинг от греха подальше отключается
Деплой одна из самых частых причин отказов на проде (особенно в пятницу вечером), поэтому метод деплоя стоит выбирать исходя из скорости отката в случае, если на прод все же удалось прокрасться битому релизу
Поскольку с распространением оркестрации все проще реализовывать самые замысловатые стратегии, то все чаще используется не какая-то одна парадигма, а все сразу, когда на проде можно увидеть одновременно несколько канареек и линий деплоя, по которым шрединг-кот раскатывает огромный клубок деплоя со шрединг-багом. А невдалеке под закатным кактусом, Ковбой Билл, с наполовину пустой бутылкой текилы, уже готов внести непоправимые улучшения в архитектуру, которые его коллеги обязательно оценят, как только над остывающим продакшеном взойдет одинокая луна
Знаете Яблочный Спас? Он спасал.