Skip to content
概述
在多人协作的软件开发中，代码集成与发布的方式直接影响交付效率和质量。在没有自动化手段之前，这些环节通常依赖人工操作和固定的“集成日”，问题会随着项目规模的增长集中爆发。持续集成（Continuous Integration，CI）、持续交付（Continuous Delivery）和持续部署（Continuous Deployment）——统称 CI/CD——正是为了解决这些问题而出现的工程实践。
CI/CD 并不是单一的工具或流程，而是一组相互递进的自动化策略。它们的共同目标是：让代码变更能够频繁、可靠地合入主干，并快速交付到可运行环境，同时用自动化检查替代人工验收，缩短从提交到获得反馈的时间。
手动集成与发布的问题
在 CI/CD 普及之前，一个典型的功能开发流程大致如下：
- 多名开发者各自在特性分支上工作，数天甚至数周都不合入主干。
- 到了事先约定的“集成日”，所有人一次性把代码合并到主干，然后手动执行构建和测试。
- 如果构建失败或测试报错，就需要花费大量时间定位是谁的改动引起的问题。合并冲突也集中爆发，解决冲突本身就可能耗时很久。
- 确认所有问题修复后，再按照操作文档手动部署：打包文件、上传到服务器、重启服务、切换流量。每一步都依赖人的记忆和操作准确性。
这种做法带来的痛点非常直接：集成频率越低，冲突越多，合并难度越大；构建和测试依赖人工触发，从代码提交到发现错误可能已经过去好几天；手动部署极易出错，环境配置差异、步骤遗漏都会导致上线故障；整个交付周期过长，一个功能往往需要数周甚至数月才能到达用户。
缩短反馈周期、降低集成成本，就是 CI/CD 最初的出发点。
持续集成
基本概念
持续集成（Continuous Integration，CI）要求开发人员每天多次将代码变更合入主干分支。每次合入都会自动触发构建和全量测试，以便尽早发现集成错误。
这与过去“等所有功能开发完再一起合并”的做法相反。CI 追求的是“早合并、常合并、小步快跑”。每一次提交都必须在集成过程中通过自动化检验。
工作原理
一个最基本的 CI 流程通常包含两步：构建和测试。以 Node.js 项目为例，本地开发时开发者可能会执行：
bash
npm install
npm run build # 对应 tsc 或类似编译器
npm test # 执行 Jest在 CI 环境里，这些步骤会被编排成一个自动化流水线。下面是一个不针对特定平台的配置片段，仅用于示意：
yaml
steps:
- run: npm ci # 依据 package-lock.json 精确还原依赖
- run: npm run lint # 静态检查
- run: npm test # 单元测试与集成测试
- run: npm run build # 构建产物每当有新提交推送到主分支，CI 服务会自动拉取代码并顺序执行上述步骤。如果任何一步返回非 0 的退出码，整个流水线就会被标记为失败，并立即通知提交者和团队。
这样一来，集成错误从出现到被发现往往只需要几分钟。开发者对代码变更的印象还很清晰，修复成本远低于几天之后再排查。CI 本身并不直接负责部署，它的目标是保证主干分支的代码始终处于可编译、可测试、可验证的状态。
持续交付与持续部署
基本概念
在 CI 的基础上，持续交付（Continuous Delivery）增加了更多的自动化测试，包括集成测试、回归测试、API 可靠性测试等，目的是让每一次通过全部检查的代码变更都达到“随时可以部署到正式环境”的就绪状态。不过，真正触发部署到正式环境仍需要人工操作——例如点击“发布”按钮或执行一条发布命令。这一层人工审批是持续交付与持续部署的关键区别。
持续部署（Continuous Deployment）则进一步去掉了人工触发的环节。只要代码通过了流水线中所有的自动化检查，就会直接部署到正式环境，无需任何人批准。 对于许多面向终端用户的 SaaS 产品，持续部署可以让一个新功能在几十分钟甚至几分钟内交付到用户手中。团队需要用足够严格的自动化测试与质量门禁来替代人工审批。
工作原理示意
一个体现持续交付理念的简化脚本可以是：
bash
# 自动化测试已通过，生成产物
npm run build
# 将产物推送到制品仓库（示意）
npm run publish:artifact
# 之后由人工决定何时执行部署即使还没有执行最终部署，此时的代码已经经过充分验证，可以随时走向用户，这是持续交付带来的核心信心。
持续部署则是在流水线末尾增加一步自动部署：
yaml
steps:
# ...前面的检查步骤...
- run: npm run deploy:live # 直接部署至正式环境这里的 npm run deploy:live 可能对应调用云平台 API、执行容器滚动更新，或上传静态资源到 CDN 等操作。部署完成后，用户即可访问新版本。同时，持续部署要求具备可靠的自动回滚手段——一旦线上指标出现异常，系统能快速恢复到上一个健康的版本。
注意点
持续交付与持续部署并不互斥，它们反映了自动化程度的不同选择。在实际团队中，往往先实现持续交付，再根据业务需要和风险承受能力演进到持续部署。两者常被统称为 CD，但需要根据上下文区分钟是交付还是部署。
CI/CD 流水线的雏形
下面通过一个简化的 Node.js 项目展示一条基本 CI/CD 流水线可能长什么样。这里不依赖任何特定平台，只用脚本和文字描述执行流程。
假设项目结构如下：
├── src/
├── tests/
├── package.json
└── .gitignorepackage.json 中定义了以下脚本：
json
{
"scripts": {
"lint": "eslint src/",
"test": "jest --coverage",
"build": "tsc -p tsconfig.json",
"archive": "tar -czf dist.tar.gz dist/",
"deploy:staging": "scp dist.tar.gz user@staging:/var/www"
}
}仓库根目录可以放置一个 ci.sh 模拟流水线执行逻辑：
bash
#!/bin/bash
set -e # 任何命令失败立即退出
echo "=== 安装依赖 ==="
npm ci
echo "=== 静态检查 ==="
npm run lint
echo "=== 测试 ==="
npm test
echo "=== 构建 ==="
npm run build
echo "=== 打包 ==="
npm run archive
echo "=== 部署至测试环境 ==="
npm run deploy:staging
echo "流水线完成"如果配置为每当主分支有新推送时由某个 webhook 调用该脚本，就具备了一条简化 CI/CD 流水线的雏形。如果将最后一步 deploy:staging 替换为自动部署到正式环境，并增加端到端测试和更严格的质量门禁，它就演变成了持续部署的形态。
实际系统中还需要处理机密信息、环境变量、制品存储、通知等细节，但上述结构展示了核心步骤的串联方式。
三者的关系
持续集成、持续交付、持续部署是递进的自动化层次：
- 持续集成（CI）：频繁合入 + 自动构建与测试，保障代码可集成。
- 持续交付（CD）：在 CI 基础上确保代码随时可以部署，但部署动作由人工触发。
- 持续部署（CD）：在持续交付的基础上自动完成部署，无需人工干预。
可以把它们理解为一条流水线不断向右延伸：CI 构建质量基础，持续交付让发布变得可预测，持续部署追求极致的交付效率。
在软件生命周期中的位置
在典型的软件开发生命周期中，会经历计划、编码、构建、测试、发布、部署、运维和监控等阶段。CI/CD 主要覆盖从“构建”到“部署”这几个环节：
- 编码完成后提交代码 → CI 自动拉取、构建、测试
- 测试通过 → 生成构建产物，进入制品库（持续交付）
- 若团队选择持续部署，产物会自动推送到目标环境
- 部署后，运维和监控系统开始观察服务健康状态
因此，CI/CD 管道实际上是连接开发与运维的自动化桥梁。
与 DevOps 的关系
DevOps 是一组文化、实践和工具的组合，旨在打破开发与运维之间的壁垒，让软件交付更快、更稳定。而 CI/CD 正是 DevOps 在技术层面最核心的实践之一。
如果没有自动化的 CI/CD 管道，DevOps 所提倡的“频繁交付、快速反馈、协作共享”就只能停留在理念层面。CI/CD 把这些理念落地为可重复执行的流水线，让开发团队的每一次提交都有自动化的质量守护。反过来，DevOps 的文化也为 CI/CD 的落地提供了组织层面的支持——没有跨角色协作，自动化流程的作用会大打折扣。
快速反馈与质量保障机制
引入 CI/CD 后，从代码提交到发现集成问题的延迟从“天/周”被压缩到“分钟”。开发者在心智中仍保留着刚刚编写代码的上下文，修复错误的效率明显更高。
自动化测试套件是质量保障的核心。单元测试检查函数行为，集成测试验证模块间交互，端到端测试模拟用户操作。每次提交都必须通过这些关卡，相当于为代码库持续积累防护网。此外，CI/CD 管道还可以集成静态分析、安全扫描和依赖检查等步骤，在更早期拦截潜在风险——这些检查如果只靠人工去跑，极易被遗漏。
当出现问题时，CI/CD 管道还能提供可靠的回滚机制。制品库中保存的历史版本让正式环境可以迅速切回到一个已知正常的版本，控制影响范围。
对软件工程的影响
CI/CD 改变了团队交付软件的方式。交付单位从过去动辄数月的“大版本”变成了每天甚至多次的“小变更”。高频发布意味着单次变更的风险大幅降低——变更范围越小，定位和修复问题就越容易。
自动化流水线让部署不再是一种特殊事件，而成为一种常规操作。发布日的心理压力显著减小，“深夜上线”的窗口也逐渐消失。对开发人员来说，可以更快地在真实环境中验证设计，并根据用户反馈做出调整，整个产品迭代的反馈循环缩短，这是根本性的提速。
下一步
本文多次提到“流水线”，但尚未拆解其内部结构。下一篇文章会正式介绍流水线的组成单元：阶段（Stage）、任务（Job）和步骤（Step），并结合具体的配置语言展示如何组织一个更完整的构建-测试-部署流程。