Какие подходы к CI/CD и деплою (deploy) ты знаешь?

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

1. Rolling Update (Постепенное обновление) Стандартный подход в Kubernetes. Новые поды запускаются, а старые завершаются по одному.

• Плюсы: Нет простоя, минимальное потребление ресурсов.
• Минусы: На короткое время работают две версии приложения, что может создать проблемы с совместимостью.
• Пример (Kubernetes):

  # deployment.yaml
  spec:
    strategy:
      type: RollingUpdate
      rollingUpdate:
        maxUnavailable: 1  # Максимум один недоступный под
        maxSurge: 1        # Максимум один дополнительный под

  Запуск: kubectl apply -f deployment.yaml.

2. Blue-Green Deployment Разворачиваются две идентичные среды: «синяя» (активная) и «зелёная» (новая). После тестирования «зелёной» среды на неё переключается весь трафик.

• Плюсы: Мгновенный и чистый переключение, быстрый откат (переключение обратно).
• Минусы: Требует в 2 раза больше ресурсов на время деплоя.
• Пример: В AWS это реализуется через переключение Target Group в Application Load Balancer.

3. Canary Release (Канареечное развертывание) Новая версия разворачивается для небольшого процента пользователей/трафика. На основе метрик (ошибки, latency) принимается решение о полном rollout или откате.

• Плюсы: Снижает риск, позволяет тестировать в продакшене на реальных пользователях.
• Минусы: Требует сложной настройки маршрутизации и продвинутого мониторинга.
• Пример (Istio VirtualService):

  apiVersion: networking.istio.io/v1beta1
  kind: VirtualService
  spec:
    hosts:
    - my-app
    http:
    - route:
      - destination:
          host: my-app
          subset: v1
        weight: 90  # 90% трафика на старую версию
      - destination:
          host: my-app
          subset: v2
        weight: 10  # 10% трафика на новую версию

4. Feature Flags (Флаги функций) Новый код деплоится для всех, но включается через конфигурацию. Позволяет управлять функциональностью без повторного деплоя.

• Плюсы: Разделение деплоя и релиза, возможность A/B-тестов, мгновенное отключение фичи.
• Минусы: Усложняет код, требует инструмента для управления флагами (LaunchDarkly, Unleash).

В проектах мы чаще всего комбинируем Rolling Update для микросервисов с Feature Flags для управления рисками по критичным фичам.