CI/CD 概念与意义
说实话，我刚入行那会儿，对「持续集成」「持续交付」这些词也是一头雾水。直到亲手搭建过几条流水线，踩过不少坑，才真正理解它们的价值。今天咱们就把这几个概念掰开揉碎聊一聊——不整虚的，全是干过的经验。
持续集成（Continuous Integration，CI）
定义：持续集成指的是开发人员频繁地将代码变更合并到主干分支，每次合并后都自动触发构建和测试，尽早发现集成问题。
为什么需要 CI？你想想看，传统开发模式下，大家各自在分支上写代码，等开发完了再合并，那场面——冲突一堆，测试全挂，修修补补又几天。我接手过一个遗留项目，团队 8 个人，两周才合一次代码，每次合并都要花一整天解决冲突。后来改成每天至少合并一次，配合自动构建，问题发现的时间从周级缩短到分钟级。
CI 的核心价值：
- 快速反馈：提交代码后几分钟内就知道是否破坏了构建或测试。
- 减少集成痛苦：小步提交，冲突范围小，容易定位。
- 保证代码质量：每次变更都经过自动化检查（单元测试、lint、静态分析）。
- 提升团队信心：主干始终保持可发布状态（理论上）。
这里有个常见的误解——「我每次提交都跑一下测试就算是 CI 了」？没那么简单。CI 要求主干分支不能提交有问题的代码，也就是必须通过所有 CI 检查才能合入。我在项目中遇到过团队把「CI 通过率」设成 98% 就觉得够了，结果那 2% 的失败提交经常卡住后续发布。后来我们改成「主干必须 100% 通过」，看似严格，实际省了很多返工时间。
避坑指南：我曾经在一个 CI 流水线里塞了太多的检查项——单元测试、集成测试、端到端测试、代码扫描、安全审计……一套跑下来 40 分钟。开发人员提交后要等半天才能得到反馈，结果大家开始「神牛式提交」：一次性攒十几个 commit 再合并。CI 失效了。后来我把流水线拆成快速门禁（3 分钟内）和异步深度检查，才回归正常。
持续交付（Continuous Delivery，CD）
定义：持续交付是在持续集成的基础上，确保软件可以随时被部署到生产环境的能力。它强调的是「可发布」的状态，但部署动作可能需要手动决策。
说白了，持续交付就是让软件从代码到生产环境之间的路径变得自动化、可重复、低风险。我个人习惯把 CD 流水线比喻成「装配线的最后一公里」——产品已经组装好、测试完，只差按下按钮就能出货。这个按钮通常需要业务或运维人员来按，但整个流程已经标准化了。
| 特性 | 持续集成（CI） | 持续交付（CD） |
|---|---|---|
| 目标 | 保证代码集成后的质量 | 保证软件随时可部署 |
| 自动化范围 | 构建、单元测试、静态分析 | 集成测试、验收测试、环境准备、发布流程 |
| 最终动作 | 生成可部署的制品 | 将制品部署到类生产环境（或生产环境） |
| 人工干预 | 通常自动合并（通过门禁） | 需要手动批准才能上线 |
我记得有个金融客户，合规要求每条发布都必须有人工审批。他们觉得持续交付意义不大——「反正都要人批，自动化有什么用？」实际上，持续交付帮他们把部署的前置时间从 2 小时缩短到 10 分钟，因为环境配置、数据库迁移、灰度策略全部自动化，审批人只需要看测试报告和变更影响，不用亲自动手执行脚本。
持续部署（Continuous Deployment）
定义：持续部署是持续交付的进阶，每一次通过自动化测试的变更都会自动被部署到生产环境，完全无需人工干预。
持续部署是 CI/CD 流水线的终极形态。但它不一定适合所有业务。我个人建议：没有完善的监控、回滚、灰度能力之前，别轻易上持续部署。我见过一个电商团队上了持续部署，结果一次数据库迁移脚本有 bug，凌晨三点部署后导致首页 502，自动回滚又因为网络问题失败，最后运维被电话叫起来手动修复。事后复盘发现，他们的测试环境数据量太小，根本覆盖不了生产流量模式的场景。
注意：
- 持续部署要求极高的自动化测试覆盖率（至少 80%+ 的代码覆盖，以及完善的集成测试）。
- 必须有灰度发布能力（金丝雀发布、蓝绿部署等）。
- 必须有一键回滚机制，且经过充分演练。
- 推荐先做持续交付，成熟后再过渡到持续部署。
什么时候适合持续部署？我总结三个特征：
- 业务场景对快速迭代的渴求远高于对稳定性的担忧（比如 A/B 实验平台、前端静态页面）。
- 团队有浓厚的自动化文化，测试、运维、开发协作紧密。
- 基础设施完备，监控告警、日志分析、限流降级一应俱全。
三者关系全景
用一个简单的流程把 CI、持续交付、持续部署串起来：
从图中可以看出：CI 负责「从代码提交到制品生成」的自动化质量保障，它结束于制品仓库。CD 接续 CI，将制品部署到目标环境。如果部署到生产环境需要手动确认，那就是持续交付；如果自动完成，那就是持续部署。
为什么这些概念对你做回归用例自动化很重要？
你想想看，回归用例自动化是 CI/CD 流水线中最关键的环节之一。没有 CI，回归测试就没法频繁触发；没有 CD，回归通过后的制品也到不了用户手中。我在设计回归用例框架时，一定先明确整个流水线的边界：
- CI 阶段：跑快速回归（核心用例、冒烟测试），反馈时间控制在 5 分钟内。
- CD 阶段：跑完整回归（全量用例、性能测试、安全扫描），可以并行、异步执行。
这套分层策略帮很多团队把回归测试从「发布前的 bottleneck」变成了「质量的守护者」。本课程后续会基于 GitHub Actions 一步步实现这套体系，今天先把概念打牢，后面实操才不飘。