很多人把 CI/CD 当成一个词来用，但实际上它是三个递进的层次。理解这三个层次的边界，决定了你团队自动化的成熟度。本篇用三个实际的流水线配置，让你直观感受从 CI 到 CD 到 Continuous Deployment 的演进。

一、三个层次的关系：一个递进模型

Level 1: Continuous Integration（持续集成）
         代码合并 → 自动构建 → 自动测试 → 反馈结果
         产出：可运行的构建产物

Level 2: Continuous Delivery（持续交付）
         CI + 自动部署到类生产环境 + 随时可发布状态
         产出：随时可以点击发布的系统

Level 3: Continuous Deployment（持续部署）
         CD + 自动发布到生产环境（无人工干预）
         产出：每次通过测试的代码自动上线

┌─────────────────────────────────────────┐
│        Continuous Deployment            │
│  ┌───────────────────────────────────┐  │
│  │      Continuous Delivery         │  │
│  │  ┌─────────────────────────────┐ │  │
│  │  │  Continuous Integration     │ │  │
│  │  │  代码 → 构建 → 测试 → 反馈   │ │  │
│  │  └─────────────────────────────┘ │  │
│  │  + 部署到预发/测试环境            │  │
│  │  + 保持随时可发布状态             │  │
│  └───────────────────────────────────┘  │
│  + 自动部署到生产环境                   │
└─────────────────────────────────────────┘

二、Level 1：持续集成（CI）长什么样

每次代码提交后自动构建和测试，快速发现问题。这个阶段不涉及任何部署。

# .gitlab-ci.yml — 仅 CI 阶段
stages:
  - build
  - test
  - scan

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"

# 构建阶段
build:
  stage: build
  image: maven:3.9-eclipse-temurin-17
  cache:
    key: maven-${CI_COMMIT_REF_SLUG}
    paths:
      - .m2/repository
  script:
    - mvn clean compile -DskipTests
  artifacts:
    paths:
      - target/
    expire_in: 1 hour
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

# 单元测试阶段
unit-test:
  stage: test
  image: maven:3.9-eclipse-temurin-17
  needs: [build]
  script:
    - mvn test
  artifacts:
    reports:
      junit: target/surefire-reports/TEST-*.xml
    paths:
      - target/site/jacoco/
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

# 代码质量扫描
code-scan:
  stage: scan
  image: sonarsource/sonar-scanner-cli:latest
  needs: [unit-test]
  script:
    - sonar-scanner
      -Dsonar.projectKey=myapp
      -Dsonar.sources=src
      -Dsonar.host.url=$SONAR_HOST
      -Dsonar.login=$SONAR_TOKEN
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

三、Level 2：持续交付（CD）多了什么

在 CI 基础上，把构建产物打包成可部署的格式（Docker 镜像），自动部署到测试和预发环境，保持系统处于"随时可发布"状态。但生产环境的发布需要人工触发。

# .gitlab-ci.yml — CI + CD（持续交付）
stages:
  - build
  - test
  - scan
  - package        # 新增：打包镜像
  - deploy-test    # 新增：部署测试环境
  - deploy-staging # 新增：部署预发环境
  - release        # 新增：准备发布（人工审批后触发）

# ... build / test / scan 同上 ...

# 打包 Docker 镜像
package:
  stage: package
  image: docker:24
  needs: [unit-test]
  services:
    - docker:24-dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

# 部署到测试环境
deploy-test:
  stage: deploy-test
  image: bitnami/kubectl:latest
  needs: [package]
  environment:
    name: test
    url: https://test.myapp.com
  script:
    - kubectl set image deployment/myapp app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA -n test
    - kubectl rollout status deployment/myapp -n test --timeout=180s
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

# 部署到预发环境（需要手动触发）
deploy-staging:
  stage: deploy-staging
  image: bitnami/kubectl:latest
  needs: [deploy-test]
  environment:
    name: staging
    url: https://staging.myapp.com
  when: manual  # ← 关键：手动触发
  script:
    - kubectl set image deployment/myapp app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA -n staging
    - kubectl rollout status deployment/myapp -n staging --timeout=180s
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

# 准备生产发布（需要人工审批）
release:
  stage: release
  when: manual  # ← 人工审批后才执行
  script:
    - echo "Release $CI_COMMIT_SHORT_SHA is ready for production"
    - kubectl label deployment/myapp -n staging release-candidate=$CI_COMMIT_SHORT_SHA
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

| 构建产物固化 | 否 | 是（Docker镜像） |

| 自动部署预发环境 | 否 | 是（可设手动触发） |

| 系统状态 | 知道代码能编译 | 随时可发布 |

四、Level 3：持续部署（Continuous Deployment）的终极形态

去掉所有人工审批环节，通过测试的代码自动部署到生产环境。这需要极高的测试覆盖率和完善的监控告警支撑。

# .gitlab-ci.yml — CI + CD + Continuous Deployment
stages:
  - build
  - test
  - scan
  - package
  - deploy-test
  - deploy-staging
  - deploy-prod      # 新增：自动部署生产环境

# ... 前面阶段同上 ...

# 部署到预发环境（自动）
deploy-staging:
  stage: deploy-staging
  image: bitnami/kubectl:latest
  needs: [deploy-test]
  environment:
    name: staging
  script:
    - kubectl set image deployment/myapp app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA -n staging
    - kubectl rollout status deployment/myapp -n staging --timeout=180s
    # 在预发环境跑冒烟测试
    - |
      for i in $(seq 1 30); do
        STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://staging.myapp.com/health)
        if [ "$STATUS" = "200" ]; then break; fi
        sleep 5
      done
      if [ "$STATUS" != "200" ]; then exit 1; fi
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

# 自动部署到生产环境（金丝雀模式）
deploy-prod-canary:
  stage: deploy-prod
  image: bitnami/kubectl:latest
  needs: [deploy-staging]
  environment:
    name: production
  script:
    # 第一步：金丝雀部署——只更新1个Pod
    - kubectl set image deployment/myapp app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA -n production
    - |
      # 等待金丝雀Pod健康
      kubectl rollout status deployment/myapp -n production --timeout=300s
      # 观察5分钟，检查错误率
      sleep 300
      ERROR_RATE=$(curl -s http://monitoring:9090/api/v1/query \
        -d "query=rate(http_requests_total{status=~\"5..\",namespace=\"production\"}[5m])" \
        | jq -r '.data.result[0].value[1]')
      if [ $(awk "BEGIN {print ($ERROR_RATE > 0.01)}") -eq 1 ]; then
        echo "Error rate too high, rolling back"
        kubectl rollout undo deployment/myapp -n production
        exit 1
      fi
    # 第二步：全量更新
    - kubectl scale deployment/myapp --replicas=10 -n production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

# 监控驱动的自动回滚（Prometheus + ArgoCD）
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  strategy:
    canary:
      steps:
      - setWeight: 10          # 10%流量到新版本
      - pause: { duration: 5m } # 观察5分钟
      analysis:                 # 自动分析指标
        templates:
        - templateName: success-rate
        args:
        - name: service-name
          value: myapp
      - setWeight: 50          # 通过后增加到50%
      - pause: { duration: 5m }
      - setWeight: 100          # 全量上线

| 信号 | CI | CD | Continuous Deployment |

|------|-----|------|----------------------|

| 部署频率 | 每周 | 每天 | 每小时 |

| 部署方式 | 手动 | 手动点击 | 全自动 |

| 监控告警 | 基础 | 完善 | 驱动回滚 |

| 团队心态 | 紧张 | 从容 | 习惯 |

：《工具链全景：Jenkins、GitLab CI、GitHub Actions、Drone 对比选型》——了解了三个层次，我们来看看实现这些层次需要哪些工具，以及如何选型。

前言 很多人把 CI/CD 当成一个词来用，但实际上它是三个递进的层次。理解这三个层次的边界，决定了你团队自动化的成熟度。本篇用三个实际的流水线配置，让你直观感受从 CI 到 CD 到 Continuous Deployment 的演进。 一、三个层次的关系：一个递进模型 Level 1: Continuous Integration（持续集成） 代码合并 → 自动构建 → 自动测试 → 反馈结果...

【CI/CD·入门篇】CI vs CD vs Continuous Deployment：三个层次的区别与联系

研发部经理

人工智能

CI/CD实为三个递进层次：持续集成（CI）自动构建测试，持续交付（CD）固化产物并部署预发环境，持续部署（Continuous Deployment）全自动上线生产。本文通过GitLab CI配置示例，对比各阶段关键差异，强调测试覆盖率、监控告警及自动回滚等前提条件，指导团队按序演进，避免跳级风险。

单元测试

数据库

GitHub

2026上云采购 | AI焕新·智启新局

coding

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

【CI/CD·入门篇】CI vs CD vs Continuous Deployment：三个层次的区别与联系

【CI/CD·入门篇】CI vs CD vs Continuous Deployment：三个层次的区别与联系

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐