深色模式
CI/CD 基础概念：流水线 stages
摘要：CI 保证「代码能合」，CD 保证「能安全交付」。本文拆开流水线的 stage / job / step 三层结构，说明每个阶段该做什么检查，并给出可照抄的阶段划分。
适用环境
- 任意 Git 仓库（GitLab / GitHub / Gitea 均可）
- 任意一个 CI 平台（本文概念通用，不绑定产品）
- 项目已有基本的构建脚本
操作步骤
1. 先分清 CI 和 CD
text
CI（持续集成）：每次提交都自动构建 + 测试，尽早发现集成问题
CD（持续交付）：随时可发布，但发布动作由人触发
CD（持续部署）：通过检查后自动发布到生产1
2
3
2
3
新手团队应先做到「持续交付」，最后一步留给人决定。
2. 三层结构：stage → job → step
yaml
stages: [build, test, deploy] # 层1：阶段，串行，任一失败则中断
build_job: # 层2：作业，同一 stage 内并行
stage: build
script: # 层3：步骤，job 内串行
- make build1
2
3
4
5
6
2
3
4
5
6
text
同一 stage 内的多个 job 并行运行
前一个 stage 全部成功才进入下一个
任一 step 返回非 0 → job 失败 → stage 失败 → 流水线终止1
2
3
2
3
3. 一条合格流水线的阶段划分
yaml
stages:
- lint # 静态检查：格式、语法、安全扫描，最快失败最便宜
- build # 编译打包，产出制品
- test # 单元/集成测试，覆盖率门禁
- publish # 制品入库，打 tag
- deploy # 部署，dev 自动 / prod 手动
- verify # 部署后冒烟，失败触发回滚1
2
3
4
5
6
7
2
3
4
5
6
7
必做项：lint 做格式与语法校验；build 保证可重复构建；test 设覆盖率阈值；publish 保证版本不可变；deploy 支持灰度与回滚；verify 做健康检查。
4. 制品只构建一次
text
错误：dev 编一次，prod 再编一次 —— 两边产物不同
正确：prod 部署的是 dev 验证过的同一个制品（同一镜像 digest）1
2
2
制品用 digest 或版本号标识，不要用 latest。
5. 失败要快速可定位
bash
set -euo pipefail
make test || { echo "tests failed"; exit 1; }1
2
2
把最便宜、最容易失败的检查放最前面，能显著缩短反馈时间。
危险
不要在流水线脚本里硬编码生产凭证。使用平台 Secret，并限制只有受保护分支能读取生产变量。
验证
bash
make lint && make build && make test # 本地先跑通 CI 同样的命令1
- [ ] 提交后流水线自动触发并按 stage 顺序执行
- [ ] 故意写错格式，lint 阶段失败且不再进入 build
- [ ] 生产部署阶段需要人工确认
常见坑
把测试写在部署之后
测试放 deploy 之后等于拿用户当测试。顺序必须是 构建 → 测试 → 部署 → 验证。
每次都从零构建
不配缓存会让流水线从几分钟变成十几分钟。依赖目录应配 cache key。
流水线能直接改生产
没有审批门禁和分支保护的 CI 等于给所有人发生产钥匙。