4. CI/CD 概述：持续集成、持续交付、持续部署的基本概念与工具链
很多刚接触兼容测试的同学问我：“为什么非要把测试塞到 CI/CD 里？手工测测不也挺好？”
我的回答通常是：你想想看，等回归测试跑完一轮，黄花菜都凉了。CI/CD 说白了就是一套自动化流水线，让代码从提交到上线变得又快又稳。而兼容测试恰恰是这条线上最容易被卡脖子的一环。
这一节，我们先把这个概念基础打牢。
4.1 三个核心概念：CI、CD、CD
这三个缩写经常放在一起说，但背后的含义和阶段完全不同。我习惯把它们看作一条流水线上的三个工位：
| 缩写 | 中文 | 核心动作 | 交付物 |
|---|---|---|---|
| CI | 持续集成 | 频繁合并代码 & 自动构建 & 自动测试 | 可验证的构建产物 |
| CD | 持续交付 | 自动部署到类生产环境 & 人工确认上线 | 随时可发布的制品 |
| CD | 持续部署 | 自动部署到生产环境 | 已上线的最新版本 |
4.2 持续集成（CI）—— 堵住“集成地狱”
我在项目中遇到过最典型的场景：5 个开发各改各的模块，到周五合并时发现冲突遍地、测试全红。这就是典型的“集成地狱”。
持续集成的做法正好相反：每人每天至少往主干合并一次代码。合并后立即触发构建和测试。这样一来，每次冲突都是小冲突，几分钟就能搞定。
CI 的关键实践我整理成了一份清单：
- 主干开发：所有工作基于主干，分支存活时间不超过一个工作日
- 自动构建：代码提交后自动编译，失败立刻通知全员
- 自动单元测试：跑完构建立刻跑单测，覆盖率不低于 80%
- 快速反馈：整个流程控制在 10 分钟以内——超过这个时间，开发者就会去看微信而不是看流水线
嗯，这里要注意：CI 的“快”比“全”更重要。优先跑关键路径的测试，而不是把全量回归放进去。我曾经见过一个团队在 CI 阶段跑完整的 UI 自动化，一次提交要等 40 分钟——后来没人愿意频繁提交了。
4.3 持续交付（CD）—— 让“发布”变成日常
持续交付在 CI 的基础上往前走了一步。CI 保证了代码能集成，持续交付保证了代码能随时发布。
具体来说，持续交付流水线会自动把构建产物部署到一个类生产环境（比如预发布环境），然后运行集成测试、性能测试、甚至兼容性测试。全部通过后，流水线准备好一个可发布的制品包，等待业务方或运维按一下“上线”按钮。
你可能会问：这和部署到底有什么区别？
区别其实就一个字：“权”。持续交付把“能不能上线”的决策权交给了人，把“上线的准备工作”交给了机器。这样既保证了效率，又保留了风控。
我在做兼容测试时特别喜欢持续交付的节奏。因为预发布环境和生产环境高度一致，很多兼容问题在预发布阶段就能暴露出来。有一次就是因为持续交付流水线跑了一轮 web 兼容性扫描，发现了某个特定浏览器下 CSS 渲染异常——要是直接进生产，估计要等用户投诉才知道。
4.4 持续部署（CD）—— 全自动上线
持续部署是 CI/CD 的终极形态，完全自动化上线，没有人工介入。听起来很爽，但门槛也最高。
要做到这一步，你至少需要：
- 极高的自动化测试覆盖率
- 完善的灰度发布和回滚机制
- 强大的监控和告警系统
- 团队对“自动化”有足够信任
不过说实话，我很少见到普通业务团队真正做到全量持续部署。更多的做法是“灰度持续部署”：先让新版在 1% 的流量上跑，确认没问题再逐步放量。这也算一种持续部署的变种。
对了，如果你要把兼容测试放进持续部署流水线，千万注意测试环境的流量隔离。我曾经因为测试环境和生产环境共用了一批浏览器实例，结果兼容测试把生产会话全部挤掉了……那次教训相当深刻。
4.5 CI/CD 工具链全景
工具本身不是重点，怎么组合才是。我习惯把工具链分成五个层次：
| 层次 | 代表工具 | 负责什么 |
|---|---|---|
| 代码托管 & 触发 | GitHub / GitLab / Bitbucket | 监听 Push / MR 事件，触发流水线 |
| 驱动引擎 | Jenkins / GitLab CI / GitHub Actions / CircleCI | 编排流水线阶段、分发任务 |
| 编译与构建 | Maven / Gradle / Webpack / Docker Build | 生成编译产物或容器镜像 |
| 测试执行 | Selenium / Appium / Playwright / Robot Framework | 运行各层次自动化测试 |
| 部署与发布 | Ansible / Kubernetes / Spinnaker / ArgoCD | 部署到目标环境、管理发布策略 |
4.6 一张图看懂 CI/CD 流程
下面这张图是我当年画给团队做培训用的。箭头方向就是代码从提交到上线的完整路径。你仔细看，每一个回流箭头都代表“发现问题—修复—重新进入流水线”。
① CI 阶段只在左边三个节点（提交→构建→集成测试）。
② 从预发布开始就进入了 CD 范围。
③ 红色虚线是失败回流——测试不过，代码打回重来。
④ 持续部署就是砍掉“人工决策”那个分支，直接从预发布走向生产。
4.7 选择工具链时我最看重的三点
工具多如牛毛，选起来容易眼花。我给自己定了三条原则，分享给你：
- 和现有技术栈匹配：Java 团队别硬上 Go 生态的 Drone，前端团队可以优先考虑 GitHub Actions。
- 插件/扩展生态够用：尤其是测试相关的插件。Jenkins 虽然老，但它的兼容测试插件比很多新工具都全。
- 团队能接手：工具再好，没人会用也是白搭。选一个团队现有能力范围内能玩转的。
我记得有一次帮一家创业公司搭流水线，他们硬选了 Spinnaker 做 CD 引擎——结果团队没有 K8s 基础，折腾一个月都没上线。后来换成 GitLab CI + 简单脚本，两周就跑通了。工具是拿来解决问题的，不是拿来炫技的。