CI/CD 基础概念：持续集成、持续部署、管道基本组成、常用CI平台对比

老规矩，咱们先理清这些术语到底在说什么。很多团队把 CI/CD 挂在嘴边，但真问起来，连持续集成和持续部署都分不清。我刚开始带无障碍测试项目的时候也踩过这个坑——配置了一堆自动化，结果发现跑的根本不是 CI 管道，充其量就是个定时脚本。所以这一章，咱们把地基打牢。

持续集成（Continuous Integration, CI）

说白了，就是开发人员频繁地把代码合并到主干，每次合并都自动触发构建和测试。核心目的是“尽早发现问题”。

• 频率：每天多次合并，而不是攒一周再合。
• 反馈：几分钟内告诉你代码有没有编译错误、测试是否通过。
• 范围：包括代码检查（lint）、单元测试、集成测试，以及我特别关心的无障碍测试。

持续部署（Continuous Deployment / Delivery, CD）

持续部署和持续交付其实有微妙的区别。我个人习惯这么区分：

• 持续交付（Continuous Delivery）：代码通过所有测试后，自动部署到类似生产的环境，但需要手动点一下才能上生产。
• 持续部署（Continuous Deployment）：没有手动按钮，只要测试全绿，直接推到生产环境。

对于无障碍测试来说，我建议至少做到持续交付。因为某些无障碍规则（比如颜色对比度）需要人工复审，完全自动化部署有时会漏掉视觉判断的问题。

管道（Pipeline）的基本组成

一条典型的 CI/CD 管道可以看作一个流水线，每个阶段完成特定任务。我自己画过一个通用模板：

1. 触发事件：代码推送（push）、合并请求（merge request）、定时任务等。
2. 构建：编译代码、打包 Docker 镜像、生成静态资源。
3. 测试：单元测试、集成测试、无障碍测试（如 axe-core、Lighthouse）。
4. 静态分析：代码质量检测、安全扫描、无障碍规则扫描。
5. 部署：推送到测试环境、预发布环境或生产环境。
6. 通知：把构建结果、测试报告通过邮件、Slack、飞书等人推送到团队。

常用 CI/CD 平台对比

选平台就像选工具，没有的好坏，只有适不适合。下面这张表对比了我用过或接触过的几个主流平台，重点标注了它们对无障碍测试的支持情况。

平台	托管方式	配置文件	无障碍支持	我个人的槽点
Jenkins	自托管	Jenkinsfile / 界面配置	需插件（如 axe Jenkins Plugin）	插件版本管理混乱，我遇到过插件冲突卡掉整个管道
GitLab CI/CD	自托管 / SaaS	.gitlab-ci.yml	原生支持自定义 Docker 镜像，无障碍工具可轻松集成	Runner 扩展性稍弱，但够用
GitHub Actions	SaaS（仅云）	.github/workflows/*.yml	市场有现成的无障碍审核 Action，如 Deque Labs 的 axe-action	免费额度少，大项目容易超额
CircleCI	SaaS	.circleci/config.yml	可通过 orb（复用模块）集成无障碍测试	自定义程度不如 GitLab，但上手快
Azure DevOps	云 / 自托管	YAML / 可视化设计器	Marketplace 有无障碍扩展，但质量参差不齐	界面臃肿，我配置一次后就不太想用第二次

一个完整的 CI/CD 管道示意图

为了让你直观理解这些概念如何串在一起，我画了一张图。从开发者推送代码开始，到最终部署上线，每个阶段都标注了关键任务和常用工具。图中特别突出了管道中的无障碍测试节点——这是咱们这门课的重点。

一点避坑心得

我曾经在一个项目中，把无障碍测试放在了管道的最末尾，也就是部署之后才跑。结果呢？部署到预发布环境后才发现大量无障碍违规，又得回滚重来。那叫一个折腾。

所以我的建议是：无障碍测试一定要放在部署之前，与集成测试并行执行。你想想看，如果每次代码变更都能在几分钟内得到无障碍报告，而不是等到第二天，那效率会提升多少？

另一个教训来自管道超时。无障碍扫描在大型项目上可能耗时较长，我曾经见过一个单页面应用用 axe-core 扫描 2000 个组件，跑了 40 分钟。后来我们拆分成多个并行 job，才把时间压到 5 分钟内。