2.2 持续交付与持续部署 (CD)

2.2 持续交付与持续部署（Continuous Delivery & Continuous Deployment）

核心摘要：持续交付（Continuous Delivery）与持续部署（Continuous Deployment）是现代软件工程中支撑高频、可靠、低风险发布的两大核心实践。二者均以自动化流水线为基石，通过版本控制、持续集成、分层测试、环境一致性与可观测性构建端到端交付能力；其本质差异在于发布决策权归属——持续交付保留人工确认环节，持续部署则将发布完全交由自动化质量门禁驱动。本文系统解析二者的技术内涵、实施路径、关键组件、实践示例及选型策略，助力团队构建可度量、可预测、可回溯的现代化软件交付体系。

1. 持续交付（Continuous Delivery）

持续交付是一种软件工程实践，旨在通过高度自动化的构建、测试与部署流水线，确保代码变更在任意时刻均处于可安全发布至生产环境的状态。其核心目标并非追求“每刻发布”，而是保障发布能力的常态化、可验证性与低风险性——即当业务需要发布时，团队能在数分钟内完成验证并上线，而非耗费数日进行回归与协调。

1.1 持续交付的核心流程

持续交付流程强调质量左移与环境一致性，典型阶段如下：

✅ 关键认知：持续交付不等于“每日发布”，而是将“发布”从高风险操作转变为低风险、可重复、可审计的常规动作。人工发布决策（如选择发布窗口、业务灰度节奏）仍保留在流程末端，由产品与运维团队协同确认。

1.2 持续交付技术栈全景

1.3 持续交付实践示例

1.3.1 Jenkins声明式流水线（支持预发布环境部署）

pipeline {
    agent any
    environment {
        APP_NAME = 'myapp'
        STAGING_URL = 'http://staging.example.com'
    }
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Build & Unit Test') {
            steps {
                sh './gradlew clean build test --no-daemon'
                junit 'build/test-results/test/TEST-*.xml'
                sh './gradlew jacocoTestReport'
                publishCoverage adapters: [jacocoAdapter('build/reports/jacoco/test/jacocoTestReport.xml')]
            }
        }
        stage('Static Analysis') {
            steps {
                sh 'sonar-scanner -Dsonar.projectKey=${APP_NAME} -Dsonar.sources=src'
            }
        }
        stage('Build Docker Image') {
            steps {
                script {
                    docker.build("${APP_NAME}:staging-${BUILD_ID}")
                }
            }
        }
        stage('Deploy to Staging') {
            steps {
                sh 'docker-compose -f docker-compose.staging.yml down'
                sh 'docker-compose -f docker-compose.staging.yml up -d'
                timeout(time: 5, unit: 'MINUTES') {
                    waitUntil {
                        sh "curl -f -s ${STAGING_URL}/health || exit 1"
                        return true
                    }
                }
            }
        }
        stage('Run Integration Tests') {
            steps {
                sh './gradlew integrationTest --no-daemon'
            }
        }
        stage('Manual Approval for Production') {
            steps {
                input message: "Ready to deploy ${APP_NAME} v${BUILD_ID} to production?", ok: "Deploy"
            }
        }
    }
}
​

1.3.2 生产就绪型Dockerfile（多阶段构建 + 安全加固）

# 构建阶段：使用完整JDK环境编译
FROM openjdk:17-jdk-slim AS builder
WORKDIR /app
COPY . .
RUN ./gradlew clean build --no-daemon

# 运行阶段：仅含JRE的极简镜像
FROM openjdk:17-jre-slim
WORKDIR /app
COPY --from=builder /app/build/libs/*.jar app.jar

# 安全加固
USER 1001:1001
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD curl -f http://localhost:8080/actuator/health || exit 1

ENTRYPOINT ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "app.jar"]
​

💡 实践提示：该流水线在预发布环境部署后执行集成测试，通过后触发人工审批节点。审批通过即进入生产部署阶段（示例中省略，可复用Deploy to Staging逻辑并替换为生产K8s集群配置），体现持续交付“就绪即发、按需发布”的本质。

2. 持续部署（Continuous Deployment）

持续部署是持续交付的演进形态，其核心定义是：所有通过完整自动化质量门禁的代码变更，不经人工干预，自动部署至生产环境。它将发布决策权完全移交至质量数据——当单元测试、集成测试、性能基线、安全扫描、A/B测试分流结果全部达标时，系统即刻执行生产发布。该模式适用于对发布时效性、迭代速度与工程成熟度要求极高的场景（如SaaS平台、实时推荐引擎）。

2.1 持续部署的核心流程

持续部署流程在持续交付基础上强化生产环境安全网与实时反馈闭环：

⚠️ 前提条件：持续部署要求组织具备高成熟度的自动化测试覆盖（≥90%核心路径）、完善的可观测性基建、明确的SLO定义、以及快速回滚能力（平均恢复时间MTTR＜5分钟）。未达标的团队强行实施将显著增加生产事故风险。

2.2 持续部署技术栈增强版

2.3 持续部署实践示例

2.3.1 Argo Rollouts金丝雀发布配置（Kubernetes）

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp-rollout
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myrepo/myapp:v1.2.0  # 新版本镜像
        ports:
        - containerPort: 8080
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 600}  # 10%流量，观察10分钟
      - setWeight: 30
      - analysis:
          templates:
          - templateName: success-rate
          args:
          - name: service-name
            value: myapp
      - setWeight: 60
      - pause: {duration: 300}  # 60%流量，观察5分钟
      - setWeight: 100
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
  - name: service-name
  metrics:
  - name: success-rate
    interval: 30s
    count: 10
    provider:
      prometheus:
        address: http://prometheus.default.svc.cluster.local:9090
        query: |
          100 - (sum(rate(http_requests_total{service='{{args.service-name}}',status=~'5.*'}[5m])) 
          / sum(rate(http_requests_total{service='{{args.service-name}}'}[5m])) * 100)
    threshold: "99.5"  # 错误率低于0.5%才继续
​

2.3.2 Jenkins持续部署流水线（集成Argo Rollouts）

pipeline {
    agent any
    environment {
        KUBE_CONFIG = '/home/jenkins/.kube/config'
        CLUSTER_CONTEXT = 'production-cluster'
    }
    stages {
        stage('Checkout & Build') {
            steps {
                checkout scm
                sh './gradlew clean build --no-daemon'
            }
        }
        stage('Run Full Test Suite') {
            steps {
                sh './gradlew test integrationTest e2eTest --no-daemon'
                sh 'chaos-mesh run network-delay.yaml'  // 注入网络延迟故障
                sh './gradlew chaosTest --no-daemon'     // 验证故障下服务可用性
            }
        }
        stage('Build & Push Image') {
            steps {
                script {
                    def image = docker.build("myrepo/myapp:${BUILD_ID}")
                    image.push()
                }
            }
        }
        stage('Deploy via Argo Rollouts') {
            steps {
                sh 'kubectl config use-context ${CLUSTER_CONTEXT}'
                sh 'kubectl set image rollout/myapp-rollout myapp=myrepo/myapp:${BUILD_ID}'
                timeout(time: 30, unit: 'MINUTES') {
                    waitUntil {
                        sh 'kubectl argo rollouts get rollout myapp-rollout --output jsonpath="{.status.phase}" | grep -q "Healthy"'
                        return true
                    }
                }
            }
        }
        stage('Verify Production SLI') {
            steps {
                script {
                    def successRate = sh(
                        script: 'curl -s "http://prometheus:9090/api/v1/query?query=avg_over_time(success_rate{job=\"myapp\"}[1h])" | jq -r ".data.result[0].value[1]"',
                        returnStdout: true
                    ).trim()
                    if (successRate.toBigDecimal() < 99.5) {
                        error "Production SLI failed: success_rate=${successRate}%"
                    }
                }
            }
        }
    }
}
​

🔍 流程解析：该流水线在构建镜像后，通过kubectl set image触发Argo Rollouts金丝雀发布。Rollouts控制器依据AnalysisTemplate持续查询Prometheus指标，若错误率超标则自动暂停发布并告警。流水线末尾强制验证生产环境核心SLI，未达标则中断流程，确保“自动发布”不等于“盲目发布”。

3. 持续交付与持续部署的深度对比

3.1 选型决策框架

选择持续交付或持续部署，不应仅基于技术可行性，更需结合业务属性、合规要求、团队能力与风险偏好综合判断：

• ✅ 优先选择持续交付：

  • 受严格监管（GDPR、HIPAA、等保三级）；
  • 发布涉及硬件集成或物理交付（如IoT固件）；
  • 核心系统变更需跨部门协同（法务、市场、客服同步准备）；
  • 团队自动化测试覆盖率＜75%，或可观测性基建尚未覆盖核心链路。

• ✅ 可推进持续部署：

  • 已实现100%容器化与Kubernetes编排；
  • 核心业务SLI（如API成功率、P95延迟）已定义并持续监控；
  • 具备分钟级自动化回滚能力（如K8s Deployment历史版本一键回退）；
  • 团队建立“故障即学习”文化，每次生产事件均输出可执行改进项。

🌟 演进路径建议：从持续集成（CI）→ 持续交付（CD）→ 持续部署（CD）是渐进式能力升级。建议以3个月为周期设定里程碑：
第1季度：实现主干分支自动构建+单元测试+预发布部署；
第2季度：补全集成测试+安全扫描+人工审批发布；
第3季度：接入Prometheus+Grafana+Argo Rollouts，对非核心服务试点金丝雀发布。

结语：构建面向未来的交付能力

持续交付与持续部署绝非简单的工具链堆砌，而是软件交付范式的根本性重构——它要求组织将质量内建于每个开发环节，将运维能力左移到代码提交瞬间，将业务价值流（Value Stream）从需求提出到用户获益的周期压缩至极致。真正的交付效能，不在于流水线运行速度，而在于团队能否基于可信的数据（而非经验直觉）做出发布决策，能否在毫秒级监控中感知用户真实体验，能否在故障发生时以自动化方式守护业务连续性。

当交付能力成为组织核心竞争力，每一次代码提交，都不再是孤立的技术动作，而是业务价值流动的坚实节拍。