Deployment

Green-Blue Deployment

При этой стратегии создается полная копия инфраструктуры (Green) для новой версии приложения, а затем постепенно перенаправляется трафик на нее, оставляя предыдущую версию (Blue) работающей параллельно. Это обеспечивает возможность быстрого отката в случае проблем и минимизирует риски простоя системы.

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

Сине-зелёный деплой также даёт вам возможность быстро откатиться до старого состояния: если что-то пойдет не так, переключите роутер обратно на синий продакшен. Но вам всё ещё придётся справляться с пропущенными транзакциями, пока зелёный продакшен активен, и, в зависимости от структуры кода, вы сможете направлять транзакции в оба продакшена, чтобы сохранять синий как резервную копию, при активном зелёном. Или можете перевести приложение в read-only режим, перед синхронизацией, запустить его на время в этом режиме, а потом переключить в режим read-write. Этого может оказаться достаточно, чтобы избавиться от многих нерешенных проблем.

Canary Deployment (канареечные релизы)

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

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

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

Blue-Green-Canary Deployment

Это комбинированная стратегия, объединяющая элементы Green-Blue и Canary деплоя. При этом создается новая версия (Blue), которая постепенно внедряется на ограниченный набор серверов или пользователей (Canary). После проверки и удовлетворения результатами, новая версия становится основной (Green), а предыдущая версия сохраняется в качестве резервной.

Shadow Deployment (теневой)

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

Rolling Deployment (плавный деплоймент)

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

A/B Testing (A/B тестирование)

Эта стратегия предполагает разделение пользователей на две группы: одна получает новую версию приложения (группа A), а другая продолжает использовать предыдущую версию (группа B). Это позволяет сравнить производительность, стабильность и пользовательский опыт между версиями и принять решение о полном переходе на новую версию.

Feature Toggles (фич-тоглы)

Эта стратегия позволяет включать и отключать определенные функциональные возможности приложения в зависимости от конфигурации. Таким образом, можно поэтапно вводить новые функции или экспериментировать с разными вариантами, не влияя на работу основного приложения.

Traffic Splitting (разделение трафика)

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

Immutable Infrastructure (неизменяемая инфраструктура)

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

Blue-Green-Red Deployment

Это расширенная версия Blue-Green деплоя, в которой предусмотрено наличие третьей окружения (Red), используемого для разработки и тестирования новых функций. При этом Blue и Green окружения остаются стабильными и готовыми к использованию, а Red используется для экспериментов и разработки.

Список стратегий деплоя

• Green-Blue Deployment
• Canary Deployment
• Rolling Deployment
• A/B Testing
• Blue-Green-Canary Deployment
• Shadow Deployment
• Feature Toggles
• Traffic Splitting
• Immutable Infrastructure
• Blue-Green-Red Deployment
• Rolling Updates
• Recreate Deployment
• Traffic Mirroring
• Dark Launching
• Forking
• Phased Rollout
• Ring Deployment
• Delta Deployment
• Staged Rollout
• Live Migration
• Binary Delta Deployment
• Hybrid Deployment
• Multi-Armed Bandit
• Traffic Shifting
• Zero Downtime Deployment
• Chaos Engineering
• Parallel Deployment
• Incremental Deployment
• Strangler Pattern
• Hot Patching