Что такое второе CD в CI/CD/CD?

Что означает второе CD в CI/CD/CD?

В классической аббревивиатуре CI/CD второе CD традиционно означает Continuous Delivery (Непрерывная доставка). Однако в современной практике, особенно в контексте полноценного DevOps-цикла, часто встречается расширенная формулировка CI/CD/CD, где второе CD действительно означает Continuous Delivery, а третье CD — Continuous Deployment (Непрерывное развертывание). Это не опечатка, а отражение эволюции практик автоматизации программного обеспечения.

Ключевые различия: Delivery vs. Deployment

Хотя термины часто используют как синонимы, между ними есть фундаментальное концептуальное и практическое различие:

Continuous Delivery (Непрерывная доставка)

Это практика обеспечения постоянной готовности кода к развертыванию в production-среде. Ключевая характеристика — процесс полностью автоматизирован до стадии выпуска, но само развертывание требует ручного одобрения (например, кликом кнопки "Deploy" или принятием бизнес-решения).

Характеристики Continuous Delivery:

• Код автоматически проходит весь цикл сборки, тестирования и подготовки артефакта.
• Артефакт (Docker-образ, пакет) помещается в репозиторий, готовый к развертыванию.
• Развертывание в production — контролируемый, часто ручной шаг.
• Основная цель: минимизировать time-to-market и снизить риски за счет полной автоматизации подготовки.

Пример пайплайна Continuous Delivery в GitLab CI:

# .gitlab-ci.yml
stages:
  - build
  - test
  - package
  - deploy-to-staging
  # Заметка: стадии deploy-to-production нет, она выполняется вручную через UI

build:
  stage: build
  script:
    - docker build -t my-app:$CI_COMMIT_SHA .

test:
  stage: test
  script:
    - docker run my-app:$CI_COMMIT_SHA npm test

package:
  stage: package
  script:
    - docker tag my-app:$CI_COMMIT_SHA my-registry.com/my-app:$CI_COMMIT_SHA
    - docker push my-registry.com/my-app:$CI_COMMIT_SHA
  only:
    - main # Артефакт готовится только для main ветки

deploy-to-staging:
  stage: deploy-to-staging
  script:
    - kubectl set image deployment/my-app app=my-registry.com/my-app:$CI_COMMIT_SHA -n staging
  only:
    - main

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

Continuous Deployment (Непрерывное развертывание)

Это следующая ступень автоматизации, где каждое успешное изменение, прошедшее весь автоматизированный конвейер, автоматически развертывается в production-среде. Человеческое вмешательство отсутствует.

Характеристики Continuous Deployment:

• Полностью автоматизированный цикл "от коммита до production".
• Требует исключительно высокого уровня доверия к автоматизированным тестам и процессам мониторинга.
• Позволяет реализовать максимально частые и небольшие релизы.
• Основная цель: полностью исключить задержки между разработкой и получением ценности пользователем, реализовать true agile.

Пример условного перехода к Continuous Deployment (дополнение к предыдущему YAML):

# Добавляем полностью автоматическую стадию для production
deploy-to-production:
  stage: deploy-to-production
  script:
    - kubectl set image deployment/my-app app=my-registry.com/my-app:$CI_COMMIT_SHA -n production
  only:
    - main
  # Ключевое отличие: нет ручных gates. Развертывание сработает автоматически.
  # На практике здесь часто добавляют сложные проверки:
  #   - условия на основе результатов нагрузочного тестирования (performance gate)
  #   - автоматический откат (rollback) при падении health-check

Эволюция: от CI к CD/CD

Исторически и концептуально это выглядит как лестница зрелости:

1. Continuous Integration (CI) – Автоматическая сборка и тестирование при каждом коммите. Фокус на качестве кода.
2. Continuous Delivery (+CD) – Автоматизация всей цепочки до production, но с ручным контролем выпуска. Фокус на готовности к релизу.
3. Continuous Deployment (++CD) – Полная автоматизация, включая выпуск в production. Фокус на скорости доставки ценности.

Почему это важно для DevOps-инженера?

Понимание этой градации критически важно, потому что:

• Выбор стратегии зависит от бизнес-требований, регуляторных ограничений (например, в fintech или медицине) и зрелости команды. Не всегда Continuous Deployment — это правильно.
• Архитектура и инструменты требуют разной настройки. Для Continuous Deployment необходимы продвинутые механизмы синего-зеленого развертывания (blue-green deployment), канареечных релизов (canary releases) и автоматического отката (auto-rollback) для минимизации рисков.
• Культура и процессы: Continuous Deployment требует культуры высочайшего качества кода, полного покрытия автотестами и развитого мониторинга (observability).

Таким образом, второе CD в цепочке CI/CD/CD — это мост между автоматизацией разработки и автоматизацией бизнеса. Continuous Delivery гарантирует, что мы можем выпускать быстро и безопасно, когда это нужно бизнесу. Continuous Deployment делает этот выпуск частью технического процесса, максимизируя скорость обратной связи. Задача DevOps-инженера — построить такой конвейер и культуру, которые соответствуют целям и возможностям конкретной организации.