CI/CD 入门：让代码自己跑测试、自己上线

你一定经历过这种场景：功能写完了，要上线。于是你手动把代码打包、传到服务器、重启服务，中间手抖配错一个环境变量，网站直接白屏。更惨的是，同事也改了同一份代码，你俩的代码一合并，谁也没测过”合起来能不能跑”，线上直接炸。

这就是传统”手工发布”的痛点：人为操作多、容易出错、合并即爆炸、回滚靠运气。而 CI/CD 就是来消灭这些痛点的——它把”集成、测试、打包、部署”这些原本靠人肉敲命令的事，变成一条自动跑的流水线。

这一篇我们不讲具体工具（下两篇讲 GitHub Actions 和 GitLab CI），先把”CI/CD 到底是什么、为什么有用、流水线长什么样”这个底层认知打牢。

CI 和 CD 到底指什么

很多人口头上把 CI/CD 当一个词，但其实它拆成三段，含义完全不同：

CI（Continuous Integration，持续集成）：开发者频繁地把代码合并到主分支（比如一天多次），每次合并都自动触发”拉代码 → 装依赖 → 编译 → 跑测试”。目的是尽早发现”合并不兼容""测试挂了”这类问题，而不是等到上线前才爆。
CD 有两层意思：
- Continuous Delivery（持续交付）：代码通过所有自动化测试后，自动打包成”随时可发布”的产物，但最后一步上线由人点一下按钮确认。
- Continuous Deployment（持续部署）：连”人点按钮”都省了，测试通过就自动上线到生产环境。

一句话区分：CI 管”合代码并验证”，CD 管”把验证过的代码交付/部署出去”。新手常混淆 Delivery 和 Deployment，记住：Delivery 是”准备好了，等你批准”，Deployment 是”我直接给你上了”。

想象一个三人小团队，全靠手工：

问题根源在于：“本地能跑”不等于”合起来能跑”，更不等于”线上能跑”。人的记忆和手速不可靠，环境也各不相同。

引入 CI 后，规则变了：任何人往主分支推代码，机器立刻把”所有人的代码合在一起”重新编译、跑全套测试。只要有一个人引入的改动让测试挂了，立刻红灯报警，问题在”合并的那一刻”就被逮住，而不是拖到上线夜。

把 CI/CD 画成一条从左到右的管道，每个环节叫一个 Stage（阶段），代码像水一样流过去，任何一环失败就整体变红、停止：

代码推送 → [拉取代码] → [安装依赖] → [代码检查/编译] → [跑测试] → [构建镜像/打包] → [部署到环境]

逐个阶段解释：

关键设计：前一个阶段失败，后面全部跳过。比如测试挂了，就别浪费时间部署了，立刻通知人去修。这叫”快速失败（fail fast）“。

它带来的好处是实打实的：

试着用”提交代码后，机器会自动做 X、Y、Z”的句式，描述你理想中的流程。比如：“我往 main 推代码后，GitHub 会自动拉代码、装依赖、跑 pytest、构建 Docker 镜像，并部署到测试环境。“——能说清楚这句话，你就已经具备设计流水线的思维了。

下一篇我们就把这个想法落地：用 GitHub Actions 真写一个能”推代码就自动跑测试”的工作流。

问题一：CI 和 CD 的核心区别是什么？答案：CI 关注”频繁合并并自动验证”，CD 关注”把验证过的代码交付/部署出去”；CD 里 Delivery 需人工确认，Deployment 全自动。
问题二：为什么”前一个阶段失败，后面就跳过”很重要？答案：快速失败，避免在无意义的后续步骤上浪费时间和资源，并立刻把问题暴露给人。
问题三：有了 CI/CD 就可以不写测试吗？答案：不行，流水线只是自动执行者，测试本身要开发者写，否则流水线形同虚设。