让「测试、构建、部署」自动化流水化
生产级交付的重要一环是 CI/CD：把代码从「提交」到「上线」的重复过程自动化、标准化。这一节打基础：CI/CD 是什么、主流平台有哪些、流水线长什么样。
什么是 CI 和 CD
两个词，先分清：
| 全称 | 干什么 | |
|---|---|---|
| CI | 持续集成 | 提交代码后自动「构建 + 测试」，尽早发现问题 |
| CD | 持续交付/部署 | 通过验证后自动「部署」到环境 |
合起来：每次代码变动，自动经过「测试 → 构建 → 部署」的流水线。
对 deploy-bot 来说，CI 是「代码一变就自动验证」，CD 是「验证过了就自动部署」——而 deploy-bot 恰恰是那个在 CD 阶段执行部署的机器人。理解了这两层，你就知道 deploy-bot 在流水线里站哪、干什么。
为什么需要 CI/CD
没有流水线，会怎样：
- 测试靠人手动跑 → 容易漏、容易忘
- 部署靠人手动敲 → 慢、易错、不可重复
- 问题到上线才发现 → 代价巨大
有了流水线：
- 代码一提交，自动测试
- 有问题当场卡住，合不进去
- 通过就自动部署，稳定可重复
CI/CD = 把质量关卡和发布流程「自动化」。
对 deploy-bot 尤其关键：它做的是部署，而部署最怕「不可重复、靠人敲」。接进流水线后，每次部署都是同一条标准路径，可重复、可回滚、有据可查——这正是生产级部署的根基。
流水线的骨架
一条典型流水线，由几个阶段组成：
触发（提交/PR）
→ 安装依赖
→ 跑测试
→ 构建产物
→ （可选）部署
每个阶段过了才进下一个，任何阶段失败就卡住。
对 deploy-bot，理想的流水线骨架是把部署也纳入进来：
提交/PR 触发
→ 安装依赖
→ 跑测试（失败即卡）
→ 构建产物
→ deploy-bot 部署 staging
→ 验收通过
→ deploy-bot 部署 production（需门禁/人工确认）
这样，deploy-bot 的部署动作就成了流水线里自然的一环，而不是游离在外的「手动命令」。
主流平台
常见 CI/CD 平台，选一个上手即可：
| 平台 | 特点 |
|---|---|
| GitHub Actions | 和 GitHub 仓库深度集成，上手快 |
| GitLab CI | GitLab 内置 |
| Jenkins | 老牌、灵活、自托管 |
| 国内平台 | Gitee/CODING 等也提供 CI 能力 |
新手推荐 GitHub Actions：配 .github/workflows/ 一个文件即可。
选平台主要看：deploy-bot 的代码仓库托管在哪。在 GitHub 就用 GitHub Actions，在 GitLab 就用 GitLab CI。跟着仓库走，集成成本最低。
让 AI 帮你搭流水线
你可以让 Codex 帮你写流水线配置：
帮我写一个 GitHub Actions workflow：
- push 和 PR 时触发
- 跑 npm test
- 测试通过后构建
它给你一个 .yml 文件，你审查后放进去。
给 deploy-bot 搭流水线，也可以让它起草，但务必加上部署相关约束：
帮我写一个 GitHub Actions workflow 给 deploy-bot 用：
- push 和 PR 时触发
- 跑测试，失败即停
- 构建产物
- 加一个「部署 staging」阶段，用环境变量注入目标环境
- production 部署加人工确认，别自动放行
AI 起草 + 你审查，尤其部署阶段要自己把好关。
常见坑：一上来就全自动部署生产
搭 CI/CD 最常见也最冒险的坑，是「一次配成全自动，production 也自动部署」。
真实场景：你让 Codex 帮你写流水线，它写得很「完整」，连 production 部署都自动放行。第一次提交触发，代码直接上了生产——而你可能根本还没想好门禁和回滚。
为什么：全自动部署生产看起来「效率高」，但把「质量把关」和「风险控制」全交给机器，一旦流水线配错或测试没拦住，事故直接上生产，且没有人工兜底。
怎么破：按「先 staging 全自动、production 留人工确认」起步。staging 随便跑，production 部署加一道人工确认 + 回滚预案，稳定一段时间再考虑是否收紧。自动化的边界，要跟着风险走。
小结
- CI = 自动构建测试，CD = 自动部署
- 流水线 = 触发 → 测试 → 构建 → 部署
- 主流平台：GitHub Actions / GitLab CI / Jenkins / 国内平台
- 让 Codex 帮你写配置，你审查
下一节，实战把 Codex 集成进流水线。