07 - 一条 CI/CD 流水线的主流程
上一章讲了 CI/CD 解决什么问题。这一章我们拆开一条流水线（Pipeline），看看它到底分几步、每步在干嘛。搞懂这五步，你就看懂了绝大多数项目的 CI/CD。
什么是”流水线”
流水线（Pipeline）：就是一串按顺序自动执行的步骤。代码从”提交”开始，像在工厂传送带上一样，一步步经过加工，最后变成”线上运行的服务”。
触发方式：通常是你 git push 代码到仓库（或者合并一个 PR），流水线就自动开始跑。
主流程：五步
一条典型的流水线，主流程是这五步：
①拉代码 → ②装依赖 → ③跑测试 → ④构建 → ⑤部署[配图：一条从左到右的传送带，五个环节依次排开：拉代码 / 装依赖 / 测试 / 构建 / 部署，每个环节一个图标，通过则亮绿灯，任一环节失败则亮红灯并停下]
① 拉代码（Checkout）
流水线跑在一台临时的、干净的机器上（云厂商临时给你的）。第一步就是把你仓库里最新的代码拉下来。
关键点：每次都是全新干净的环境，避免”上次残留的东西”造成干扰。
② 装依赖（Install）
把项目需要的依赖装上：前端 npm install，后端 pip install -r requirements.txt。这样后面才能构建和测试。
③ 跑测试（Test）
自动运行项目里的测试用例，检查这次改动有没有把功能改坏。
这一步是 CI（持续集成） 的灵魂：测试不通过，流水线就停在这里，坏代码上不了线。 中小项目如果暂时没写测试，这步可以先跳过，但强烈建议补上。
④ 构建（Build）
把源代码变成”可以运行/发布的成品”：
- 前端：
npm run build，产出静态文件（HTML/JS/CSS） - 后端：
docker build，把代码和环境打成一个 Docker 镜像
构建产物就是要被送上线的”成品”。
⑤ 部署（Deploy）
把成品送到线上运行环境：
- 前端：把静态文件上传到 OSS，刷新 CDN
- 后端：把 Docker 镜像推送并部署到 Serverless
这一步就是 CD（持续部署）。做完，线上就是最新版本了。
一个关键原则：失败就停
流水线是从上到下顺序执行的，任何一步失败，后面的步骤立刻停止，并通知你。
- 测试没过 → 不会构建，更不会部署（保护线上）
- 构建失败 → 不会部署
这就是为什么 CI/CD 让人安心：坏东西会在半路被拦下来，而不是等它上了线才发现。
完整走一遍（脑内演练）
你改了个功能，git push：
- 流水线被触发，找一台干净机器 → 拉代码
- 装依赖 → 跑测试，测试全过 ✅
- 构建：前端出静态文件、后端打好 Docker 镜像
- 部署：前端推 OSS+CDN、后端上 Serverless
- 几分钟后，线上已经是你刚 push 的版本，你全程只按了一次 push
小结
- 流水线 = 一串按顺序自动执行的步骤，由 push 触发。
- 主流程五步：拉代码 → 装依赖 → 跑测试 → 构建 → 部署。
- 前三步偏 CI（保证代码是好的），后两步偏 CD（把成品送上线）。
- 核心原则：任一步失败就停下，坏代码进不了线上。
主流程清楚了，下一章我们落到”现代项目”里，看看这条流水线在前端和后端上具体各跑了什么。
下一章 → 08 - 现代项目里 CI/CD 具体在跑什么