В чем разница между Continuous deployment и Continuous delivery?

Разница между Continuous Deployment и Continuous Delivery

Это ключевые понятия в современных процессах разработки (DevOps), часто вызывающие путаницу. Оба являются частью Continuous Integration (CI) — практики автоматического тестирования и объединения изменений кода. Они представляют следующие этапы автоматизации, но с разной степенью конечного риска.

Определения и суть различия

Continuous Delivery (CD) — это процесс, при котором каждый успешно прошедший все этапы автоматизированного тестирования и сборки код готов к развертыванию в производственной среде в любое время. Однако сам момент развертывания — это человеческое, бизнес-решение. Код находится в состоянии постоянной готовности, но выпуск в production контролируется.

Continuous Deployment (CD) — это более продвинутая практика, при которой каждое изменение, успешно прошедшее автоматизированный конвейер (build, test, staging), автоматически развертывается в production без какого-либо человеческого вмешательства. Это полная автоматизация до конечного пользователя.

Основное отличие: точка остановки

Главное различие заключается в наличии "ручного затвора" (manual gate) перед выпуском в production.

• В Continuous Delivery такой затвор есть. Это может быть клик по кнопке "Deploy", утверждение менеджера, согласование бизнес-отдела или просто стратегический выбор времени выпуска.
• В Continuous Deployment такого затвора нет. Конвейер автоматически продвигает изменения дальше, если все проверки прошли успешно.

Практическая иллюстрация на примере iOS разработки

Рассмотрим типичный CI/CD Pipeline для мобильного приложения.

# Пример конфигурации pipeline (GitHub Actions, Bitrise, CircleCI)
name: iOS CI/CD Pipeline

jobs:
  build-and-test:
    runs-on: macOS-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Install dependencies
        run: pod install
      - name: Build for testing
        run: xcodebuild build-for-testing -workspace MyApp.xcworkspace -scheme MyApp
      - name: Run unit & UI tests
        run: xcodebuild test-without-building -workspace MyApp.xcworkspace -scheme MyApp

  # Этап, общий для Delivery и Deployment
  staging-deploy:
    needs: build-and-test
    if: success() # Запускается только если тесты прошли
    steps:
      - name: Deploy to TestFlight (Staging)
        run: scripts/deploy_to_testflight.sh
        # Здесь приложение попадает к внутренним тестировщикам

Вот как продолжается pipeline для двух разных стратегий:

# ДОПОЛНЕНИЕ для CONTINUOUS DELIVERY (с ручным затвором)
  production-ready:
    needs: staging-deploy
    if: success()
    steps:
      - name: Mark build as Production-Ready
        run: echo "Build is GREEN and ready for manual deployment."
      # ПИПЕЛINE ОСТАНОВЛЕН. Дальнейший шаг (deploy to App Store) запускается
      # по команде человека через API или кнопку в интерфейсе CI-системы.

# ДОПОЛНЕНИЕ для CONTINUOUS DEPLOYMENT (полная автоматизация)
  automatic-production-deploy:
    needs: staging-deploy
    if: success()
    steps:
      - name: Automatically upload to App Store Connect
        run: scripts/upload_to_app_store.sh
      - name: Automatic release to App Store (if approved)
        # Это возможно только если App Store Connect уже настроен на
        # автоматическое распространение после успешного review.

Почему не все используют Continuous Deployment?

Полная автоматизация до production — это идеал, но на практике, особенно в iOS разработке, ее достижение ограничено внешними факторами:

1. Review магазина приложений. App Store и Google Play имеют ручной или полуавтоматический процесс ревью. Нельзя гарантировать мгновенное развертывание. Максимум можно автоматически подать билд на проверку после успешного pipeline.
2. Бизнес-риск и стратегия. Выпуск новой версии может требовать координации с маркетингом, поддержкой, обучением пользователей. Автоматический выпуск может нанести ущерб.
3. Критические изменения. Для миграций данных, изменений API или серьезных архитектурных изменений часто нужен контролируемый, поэтапный rollout (например, через функциональные флаги).

Преимущества каждой практики

Преимущества Continuous Delivery:

• Сниженный риск: Бизнес или техлид контролирует момент выпуска.
• Гибкость выпуска: Можно выпускать фичи по стратегическому плану, объединять несколько изменений в один релиз.
• Готовность к инцидентам: Любой зеленый билд можно немедленно развернуть как "горячую" фикс, минуя очередь разработки.

Преимущества Continuous Deployment:

• Максимальная скорость feedback: Разработчики сразу видят, как их код работает в реальной среде, и получают feedback от пользователей.
• Сокращение времени от идеи до ценности: Каждая фича или улучшение доходят к пользователю мгновенно после завершения разработки.
• Устранение человеческой ошибки в процессе: Никто не забывает "нажать кнопку", процесс стандартизирован.

В iOS-контексте

Для iOS-команд Continuous Delivery — это чаще всего достижимая и оптимальная цель:

• Автоматизация: сборка -> все тесты -> загрузка в TestFlight.
• Ручной затвор: выпуск из TestFlight в App Store после внутреннего QA и бизнес-OК.

Continuous Deployment в чистом виде для App Store невозможен из-за review, но можно максимально его приблизить:

• Автоматическая загрузка каждого зеленого билла в App Store Connect.
• Настройка автоматического распространения после прохождения автоматического review (если оно есть и успешно).
• Использование механизмов типа фазативного выпуска (phased release) для контроля риска уже после публикации.

Вывод

Таким образом:

• Continuous Delivery = "Мы можем выпустить в любой момент, но решаем, когда".
• Continuous Deployment = "Мы выпускаем каждый раз, когда можем (автоматически)".

Выбор между ними зависит от культуры команды, требований бизнеса и ограничений экосистемы (как магазин приложений). В большинстве случаев команды начинают с Continuous Delivery как стабильной и контролируемой практики, стремясь максимально автоматизировать этапы в рамках Continuous Deployment там, где это не создает неоправданных рисков.