CI/CD 概念入门：持续集成与持续交付的核心思想
说实话，我刚接触 CI/CD 那会儿也觉得这玩意儿挺玄乎的。什么自动化构建、流水线、制品库……听着像是个大工程。但干久了你就发现，说白了，CI/CD 就是帮你把「写完代码 → 上线部署」这堆破事儿自动化，让你能腾出手来好好写业务逻辑。
一句话总结：CI/CD = 持续集成 + 持续交付/部署，目标是「每次提交代码都自动验证质量，随时可以一键发布」。
为什么需要 CI/CD？
你先想想看，一个团队 5 个人开发 Android App，每人每天提交 2 次代码。如果没有 CI/CD，会发生什么？
- 每次合并代码前，得手动拉下来构建一遍
- 漏跑个测试，Bug 就跑到生产了
- 发布前才想起还没做无障碍测试（比如 TalkBack 标注不全）
我经历过一次惨痛的教训：有回项目赶工期，大家各写各的，临上线前才发现某个页面 TalkBack 焦点顺序是乱的。改完代码又得重新跑全量回归测试……嗯，从那以后我就在团队里强推 CI 了。
持续集成（CI）的核心思想
持续集成，说白了就是「代码一提交，马上自动验证」。每次 push 到共享仓库，CI 工具就会拉取代码、编译、跑单元测试、做静态分析……有问题立刻通知你。
核心流程其实就三步：
- 提交代码：开发者 git push
- 自动触发构建：CI 工具监听分支变化
- 执行测试验证：单元测试 + 集成测试 + 无障碍检查（比如 TalkBack 标注校验）
我的习惯：在 CI 里加上 TalkBack 测试脚本，每次构建都跑一遍无障碍扫描工具。这样就算 UI 改动了，焦点顺序和标签都能被及时发现。
持续交付与持续部署（CD）
CI 搞定了，CD 是接下去的事。很多新人把这两个词混着用，其实有区别：
| 概念 | 做了什么 | 上线还要人么？ |
|---|---|---|
| 持续交付（Continuous Delivery） | CI 通过后，自动把构建产物发布到类生产环境，但部署到生产需要人工点一下 | 需要人工审批 |
| 持续部署（Continuous Deployment） | CI 通过后，自动部署到生产环境，完全无人干预 | 完全自动化 |
我个人建议：在 TalkBack 测试集成场景下，先用持续交付模式。因为无障碍改动有时会有意外效果，人工上线前看一眼截图比较稳妥。等测试覆盖率上来了，再考虑全自动部署。
我曾经踩过的坑：早期图省事直接上了持续部署，结果有一次 CI 误判了某个无障碍属性——颜色对比度不达标但 CI 脚本没检查到——差点把不可用的版本推到用户手里。从那以后我就在 CD 环节加了一道人肉质检门。
常用 CI 工具简介
市面上工具不少，我挑三个最常用的聊聊：Jenkins、GitLab CI 和 GitHub Actions。它们都能跑 TalkBack 测试，但配置方式和适用场景不太一样。
Jenkins
老牌选手，插件生态极其丰富。你需要自己搭服务器、装环境。优势是灵活，什么都能干；劣势是维护成本高——我记得有段时间 Jenkins 节点老是掉线，半夜爬起来重启……
GitLab CI
如果你团队用 GitLab 管理代码，那直接用 GitLab CI 就挺省事。它把 CI/CD 配置写成 .gitlab-ci.yml 文件，跟代码放一起。每次提交自动触发，有漂亮的流水线视图。
GitHub Actions
我最近的项目都在用这个，因为免费额度对中小团队足够友好。通过 YAML 文件定义工作流，市场上有大量现成的 Action 可以直接用，比如跑 Gradle 构建、上传 APK、发送通知等。
| 特性 | Jenkins | GitLab CI | GitHub Actions |
|---|---|---|---|
| 部署方式 | 自托管服务器 | GitLab 内置 / 自部署 Runner | GitHub 托管 Runner / 自托管 |
| 配置语法 | Web UI / Jenkinsfile | .gitlab-ci.yml | .github/workflows/*.yml |
| 插件/市场 | 插件非常丰富 | 模板库 + 自定义 | Actions 市场，生态极好 |
| 无障碍测试集成 | 需手动配置插件或执行命令 | 可在 job 中运行 shell 脚本 | 直接用社区 Action 或自定义脚本 |
| 适合场景 | 大型企业，已有 Jenkins 基础 | GitLab 深度用户 | 中小团队，或新手入门 |
选择建议：如果你从零开始，我推荐先试试 GitHub Actions —— 学习曲线低，文档清晰，而且直接在 GitHub 里就能看到运行结果。等后面规模大了再考虑 Jenkins 那种高度定制化的方案。
避坑指南：不管用哪个工具，一定要保证 CI 环境与开发环境尽量一致。我有一次在 GitHub Actions 上跑构建，因为 Runner 上 Gradle 版本不同，TalkBack 测试脚本居然报了一堆莫名其妙的错。后来我直接在 CI 配置里锁死了 JDK 和 Gradle 版本号，才消停。
好了，CI/CD 的概念和工具先聊到这儿。下一部分（其实就是你实操的时候）你会发现，把这些工具跟 TalkBack 测试挂上钩，才是真正的价值所在。