如果你经历过这样的场景——开发人员写完代码，用 FTP 把文件传到服务器上，手动重启应用，然后在浏览器里刷新看看有没有跑起来——你就会理解 CI/CD 出现的意义。这篇文章带你从零开始理解 CI/CD 的本质，以及它如何从一次次深夜上线的痛苦中诞生。

一、部署的黑暗时代：手动操作有多痛

在没有自动化之前，一次典型的部署流程是这样的：

二、CI/CD 是什么：拆解三个字母

CI/CD 是一个缩写，实际上包含了两个（或三个）概念：

CI：Continuous Integration（持续集成）

：开发人员把代码频繁地（每天多次）合并到主干分支，每次合并都自动触发构建和测试。

：代码冲突积攒到发版时才解决，合并地狱（merge hell）。

代码提交 → 自动拉取 → 自动构建 → 自动测试 → 结果反馈
                                          ↑
                                   失败则通知，成功则继续

CD：Continuous Delivery（持续交付）

：在 CI 的基础上，保证代码随时可以发布到生产环境。每次通过测试的代码都处于"可发布"状态，但发布动作需要人手动触发。

：发版前要准备很久，不确定当前代码到底能不能上线。

CD：Continuous Deployment（持续部署）

：在持续交付的基础上，更进一步——通过测试的代码自动部署到生产环境，无需人工干预。

一条完整的 CI/CD 流水线（Pipeline）通常包含以下阶段：

[代码提交] → [编译构建] → [单元测试] → [代码扫描] → [打包镜像] → [部署测试环境] → [集成测试] → [部署预发环境] → [验收测试] → [部署生产环境]
     ↑                                                                                                    ↓
     └────────────────────────────── 失败则中断并通知 ────────────────────────────────────────────────────┘

| 代码提交 | 触发流水线 | 流水线不启动 |

| 编译构建 | 编译代码，检查语法错误 | 立即中断，通知开发 |

| 单元测试 | 运行自动化测试 | 中断，代码有逻辑问题 |

| 代码扫描 | 静态分析，检查安全漏洞和代码规范 | 警告或中断（取决于规则） |

| 打包镜像 | 构建 Docker 镜像并推送到仓库 | 无法进入部署阶段 |

| 部署测试环境 | 自动部署到测试环境 | 测试无法进行 |

| 集成测试 | 端到端功能验证 | 中断，通知测试团队 |

| 部署预发环境 | 部署到与生产同构的环境 | 需人工排查 |

| 验收测试 | 业务验收 | 通知产品团队 |

| 部署生产环境 | 正式上线 | 回滚机制启动 |

四、一个最小 CI/CD 示例：GitHub Actions

用一个最简的例子感受 CI/CD 的运作方式。以下是一个 GitHub Actions 的 Workflow 文件：

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      # 第一步：拉取代码
      - name: Checkout code
        uses: actions/checkout@v4

      # 第二步：配置 Java 环境
      - name: Setup JDK
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'

      # 第三步：编译打包
      - name: Build with Maven
        run: mvn clean package -DskipTests

      # 第四步：运行单元测试
      - name: Run tests
        run: mvn test

      # 第五步：构建 Docker 镜像并推送
      - name: Build and push Docker image
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker push myregistry.com/myapp:${{ github.sha }}

      # 第六步：部署到测试环境
      - name: Deploy to test environment
        run: |
          ssh deploy@test-server "docker pull myregistry.com/myapp:${{ github.sha }} && docker-compose up -d"

这段配置文件做的事情：每次有代码推送到 

 分支，自动拉取代码 → 配置环境 → 编译打包 → 跑测试 → 构建镜像 → 推送到仓库 → 部署到测试服务器。全程无人值守。

| 部署频率 | 一周一次甚至一个月一次 | 一天多次 |

| 部署耗时 | 30分钟-2小时 | 3-10分钟 |

| 回滚方式 | 手动找旧包、手动替换 | 一键回滚到上一版本 |

| 团队状态 | 上线日通宵、精神紧绷 | 随时部署、心态从容 |

| 问题发现时机 | 线上用户投诉 | 自动化测试阶段就拦截 |

关键变化不只是速度提升，更重要的是

——每次部署前，你已经知道代码通过了编译、测试和扫描，而不是"祈祷它能跑起来"。

：《核心概念全解：构建、测试、集成、交付、部署与回滚》——我们将深入每个阶段的实际含义和操作细节，为后续工具实战打下认知基础。

前言 如果你经历过这样的场景——开发人员写完代码，用 FTP 把文件传到服务器上，手动重启应用，然后在浏览器里刷新看看有没有跑起来——你就会理解 CI/CD 出现的意义。这篇文章带你从零开始理解 CI/CD 的本质，以及它如何从一次次深夜上线的痛苦中诞生。 一、部署的黑暗时代：手动操作有多痛 在没有自动化之前，一次典型的部署流程是这样的： 1. 开发人员本地跑通代码，提交到 SVN/Git 2. ...

【CI/CD·入门篇】CI/CD到底是什么：从手动部署到一键上线的演进之路

研发部经理

人工智能

CI/CD彻底改变了传统手动部署模式，实现代码自动构建、测试和部署。从频繁合并代码的持续集成(CI)到一键发布的持续交付/部署(CD)，自动化流水线大幅提升部署效率与成功率。告别FTP上传、手动重启的繁琐操作，CI/CD让团队实现每日多次可靠部署，3-10分钟完成全流程，问题早发现早解决，回滚更轻松。

单元测试

测试服务

验收测试

集成测试

数据库

服务器

GitHub

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

coding

tcap

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

【CI/CD·入门篇】CI/CD到底是什么：从手动部署到一键上线的演进之路

【CI/CD·入门篇】CI/CD到底是什么：从手动部署到一键上线的演进之路

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐