CI/CD核心概念：持续集成、持续交付与持续部署的区别
嗯，聊到CI/CD，很多刚入行的同学会把这三个词混着用。我自己也经历过这个阶段——有次跟架构师汇报，我说“我们CI/CD已经做好了”，结果被追问“你指的CD是交付还是部署？”那一瞬间确实有点懵。所以这一章，咱们把这三个概念理清楚。
说白了，CI/CD是一条流水线。从你写完代码，到它安全地跑在生产环境上，中间要经过几个明确的环节。每个环节解决不同的问题，也有不同的责任人和自动化程度。
持续集成（Continuous Integration）
持续集成，我习惯叫它「代码的安检机」。每次你往主干分支推代码，自动触发编译、单元测试、代码风格检查、安全扫描。
为什么需要它？举个例子。我们团队以前是各自开发，周五下午合并代码，结果各种冲突、编译不过。后来改成每次push都跑CI，问题在几分钟内暴露，修复成本极低。
核心目标：快速发现集成错误，保持主干可构建、可测试。
典型工具：Jenkins、GitLab CI、GitHub Actions、CircleCI。
CI管道里一般包含几步（我用一个YAML片段示意）：
# .gitlab-ci.yml 示例（简化）
stages:
- build
- test
- deploy
build_job:
stage: build
script:
- mvn compile -q
- mvn package -DskipTests
test_job:
stage: test
script:
- mvn test
- sonar-scanner # 代码质量检查
deploy_job:
stage: deploy
script:
- echo "部署到测试环境"
only:
- main
看到没？“deploy”到这里就停了？没错，这里的deploy只是部署到测试环境，不是生产环境。这就是持续集成阶段——只负责验证和打包，不负责发布。
持续交付（Continuous Delivery）
持续交付=CI + 自动化部署到预生产环境 + 生成可发布版本。但生产环境的发布，必须由人「单击」确认。
为什么要留一手？我曾经在一个金融项目里，虽然自动化测试通过率100%，但业务方要求上线前必须人工验收。持续交付正好满足这个场景：所有环境都已经准备好，版本包已经打好了，可以随时一键上线。
我的经验： 持续交付适合对变更审批有严格要求的行业（金融、医疗、军工）。你可以在管道中加入人工审批阶段，用Manager Approve按钮代替自动部署。
持续交付管道比CI多了几项：
- 集成测试（API测试、契约测试）
- 冒烟测试（检查服务是否正常启动）
- 部署到staging环境
- 验收测试（手动或自动）
- 生成发布标签和变更记录
持续部署（Continuous Deployment）
持续部署是持续交付的「完全自动化版」。代码从合并到上生产，没有人手动干预。每一次commit，只要通过所有自动化关卡，就直接推给用户。
⚠️ 这不是适合所有人的模式。 只有测试覆盖率高、回滚机制完善、发布频率高的团队才敢这么玩。我见过一个创业团队直接在GitHub Actions里写deploy: production，结果一次误合并导致数据库表被删——因为没有pre-production验证步骤。
持续部署加入的关键环节：
- 灰度发布（金丝雀）——先让1%流量跑新版本，观察5分钟
- 自动回滚策略——如果错误率超过阈值，自动切回旧版本
- Feature Toggle——新功能默认关闭，通过开关控制
- 监控与告警——部署后自动抓取服务指标
三者的区别一次说透
| 维度 | 持续集成 (CI) | 持续交付 (CDelivery) | 持续部署 (CDeploy) |
|---|---|---|---|
| 触发条件 | 代码推送至共享分支 | CI通过 + 评审合并 | 预发布验证通过 |
| 对生产的影响 | 无影响，仅构建 | 影响预生产环境，生产待审批 | 直接修改生产环境 |
| 人工介入 | 通常不需要 | 需要手动确认发布 | 完全不需要 |
| 回滚频率 | 低（CI失败即阻断） | 中等（生产前发现问题） | 高（需要自动回滚能力） |
| 适用场景 | 所有团队入门必备 | 需要合规审批的成熟团队 | 高成熟度DevOps团队 |
一句话总结： CI保证代码能集成；持续交付保证代码随时可发布；持续部署保证代码自动发布。别再叫混了。
避坑指南
- 不要把CI和持续部署混为一谈。 我见过有团队在CI阶段直接部署到生产，结果一个单元测试没覆盖的bug直接影响了在线用户。
- 持续交付不是「不断的交付」。 它的意思是「每次都可以交付」，不是「每时每刻都在交付」。
- 持续部署不等于没有审批。 审批可以前置到代码评审和测试策略里，而不是放在部署按钮上。