Blue/Green Deployment — молниеносные и безопасные релизы без даунтайма

«Старое окружение — Blue. Новое — Green. Проверил, переключил трафик — всё. Если что-то пошло не так — щёлк, и обратно.»

Blue/Green Deployment — одна из самых надёжных стратегий выката приложений. Она позволяет выкатывать новые версии без простоя, а в случае проблем — моментально откатиться назад.

Что такое Blue/Green Deployment

Blue/Green Deployment — это подход, при котором у тебя есть два почти идентичных окружения:

• Blue — текущая стабильная версия
• Green — новая версия, которая готовится к переключению

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

Преимущества

• Нулевой даунтайм — переключение между окружениями занимает секунды
• Моментальный откат — никаких миграций на проде в панике
• Тестирование на боевом окружении — можно проверять Green перед включением трафика
• Прозрачность — пользователи не видят промежуточных состояний

Blue/Green vs другие стратегии

Пример пайплайна GitLab CI/CD

stages:
  - build
  - test
  - deploy-green
  - switch
  - rollback

build:
  stage: build
  script:
    - npm ci
    - npm run build

test:
  stage: test
  script:
    - npm test

deploy-green:
  stage: deploy-green
  script:
    - ./deploy.sh green
  only:
    - main

switch:
  stage: switch
  script:
    - ./switch_traffic.sh green
  when: manual
  only:
    - main

rollback:
  stage: rollback
  script:
    - ./switch_traffic.sh blue
  when: manual
  only:
    - main

Сценарий:

1. Деплоим новую версию в окружение Green
2. Тестим на реальном железе (но без пользователей)
3. Жмём ручной switch → трафик перенаправляется
4. Если всё норм — Blue можно освободить

Пример на Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    version: green
  ports:
    - port: 80
      targetPort: 8080

• У тебя два Deployment: my-app-blue и my-app-green
• Переключение — это просто смена селектора сервиса с version: blue на version: green
• Rollback = вернуть селектор обратно на blue

kubectl patch service my-app -p '{"spec":{"selector":{"version":"blue"}}}'

Rollback в пайплайне

Rollback для Blue/Green делается очень просто: это обратное переключение трафика на Blue через отдельный job в CI.

rollback:
  stage: rollback
  script:
    - kubectl patch service my-app -p '{"spec":{"selector":{"version":"blue"}}}'
  when: manual
  allow_failure: false
  only:
    - main

Можно вызывать rollback вручную или автоматически, если, например, post-deploy проверки не прошли.

Автоматический rollback

post-switch-check:
  stage: switch
  script:
    - ./healthcheck.sh
  allow_failure: true
  when: on_success
  only:
    - main

rollback:
  stage: rollback
  script:
    - ./switch_traffic.sh blue
  rules:
    - if: '$CI_JOB_STATUS == "failed"'
      when: always

• post-switch-check проверяет состояние Green после переключения
• Если фейл — GitLab автоматически триггерит rollback

Best Practices

• Включай метрики и логирование перед переключением
• Держи миграции обратимыми или выполняй их отдельно
• Для сложных сервисов — добавляй health checks на Green
• Автоматизируй rollback, не полагайся на ручную реакцию

Вывод

Blue/Green Deployment — отличная стратегия для:

• Производственных релизов без простоев
• Быстрых откатов
• Проектов, где стабильность критична

Комбинируя Blue/Green с CI/CD и rollback в пайплайне, ты получаешь гибкий и безопасный процесс деплоя, который идеально подходит и для монолитов, и для микросервисов.