Чем отличается Continuous Integration от Continuous Delivery и Continuous Deployment?

Различия между CI, CD и CD

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

Continuous Integration (CI) — Непрерывная интеграция

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

Ключевые характеристики CI:

• Автоматизированное тестирование: При каждом коммите или пуше запускается набор автоматических тестов (юнит-тесты, интеграционные тесты).
• Раннее обнаружение конфликтов: Позволяет быстро выявить ошибки, связанные с совместимостью изменений разных разработчиков.
• Фокус на стабильности кода: Гарантирует, что основная ветка (main/master) всегда находится в рабочем состоянии.

Пример типичного pipeline CI в Jenkins:

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                git 'https://github.com/myproject/repo.git'
            }
        }
        stage('Build') {
            steps {
                sh 'mvn clean compile'
            }
        }
        stage('Unit Tests') {
            steps {
                sh 'mvn test'
            }
        }
        stage('Integration Tests') {
            steps {
                sh 'mvn verify -P integration-tests'
            }
        }
    }
    post {
        failure {
            echo 'Pipeline failed! Sending notification...'
        }
    }
}

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

CD — это расширение CI. Его цель — обеспечить, что каждое изменение, прошедшее CI, можно быстро и безопасно выгрузить в производственное окружение. Ключевое отличие — наличие manual approval gate (ручного подтверждения) перед релизом.

Ключевые характеристики Continuous Delivery:

• Готовность к релизу: Код после CI проходит дополнительные этапы (пакетная сборка, тестирование производительности, безопасность) и становится готовым артефактом для релиза.
• Ручное принятие решения: Процесс автоматизирован до последнего шага. Разработчики, QA или менеджеры принимают решение о выпуске новой версии в production.
• Фокус на бизнес-контроле: Позволяет бизнесу контролировать время и частоту релизов в соответствии с маркетинговыми или операционными планами.

Пример этапов pipeline для Continuous Delivery (добавляются после CI):

# Пример конфигурации этапов в GitLab CI/CD (.gitlab-ci.yml)
stages:
  - build
  - test
  - package
  - security_scan
  - performance_test
  - deploy_to_staging
  - manual_approval  # Этап с ручным подтверждением!
  - deploy_to_production

deploy_to_staging:
  stage: deploy_to_staging
  script:
    - kubectl apply -f k8s/staging-deployment.yaml

manual_approval:
  stage: manual_approval
  when: manual  # Ключевой параметр, указывающий на ручный запуск этапа
  script:
    - echo "Waiting for approval to deploy to production..."

deploy_to_production:
  stage: deploy_to_production
  script:
    - kubectl apply -f k8s/production-deployment.yaml

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

Continuous Deployment — это наиболее автоматизированный подход. Здесь каждое успешно прошедшее CI изменение автоматически развертывается в производственное окружение без какого-либо ручного вмешательства.

Ключевые характеристики Continuous Deployment:

• Полная автоматизация: Отсутствует этап ручного подтверждения. Если все тесты и проверки пройдены, релиз происходит автоматически.
• Высокая частота релизов: Позволяет выпускать изменения мгновенно, что критически важно для продуктов, где скорость обратной реакции пользователей является ключевым преимуществом.
• Фокус на техническом совершенстве: Требует исключительно надежных процессов тестирования, мониторинга и отката (rollback), поскольку человеческий контроль отсутствует.
• Культура высокого доверия: Команда должна полностью доверять своей автоматизации и иметь быстрые механизмы исправления ошибок, если они попадут в production.

Упрощенная логика полного автоматического pipeline:

# Пример логики скрипта, реализующего Continuous Deployment
def continuous_deployment_pipeline(commit_hash):
    # 1. CI этапы
    if not run_ci_stages(commit_hash):
        log_failure_and_alert()
        return

    # 2. Дополнительные проверки для Production
    if not run_security_scan(commit_hash):
        log_failure_and_alert()
        return
    if not run_performance_baseline_check(commit_hash):
        log_failure_and_alert()
        return

    # 3. АВТОМАТИЧЕСКИЙ ДЕПЛОЙ в Production (никакого 'if approve()')
    deploy_to_production(commit_hash)

    # 4. Автоматический пост-деплой мониторинг и откат при необходимости
    if not monitor_health_after_deployment(timeout=5_minutes):
        execute_automatic_rollback(commit_hash)
        alert_team_about_rollback()

Сравнительная таблица

Вывод

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