手动上线的代价#

早年我手动 build 完 scp 到服务器，漏了一步、装错依赖，线上就挂。CI/CD 的价值：把这套流程变成”提交即触发、机器严格执行”，人不再是关键路径。

一条典型流水线#

1
push / PR
2
 └─ CI（持续集成）
3
     ├─ install（带缓存）
4
     ├─ lint            ┐
5
     ├─ typecheck       ├─ 任一失败即红，阻断合并
6
     ├─ test            ┘
7
     └─ build           ┐
8
                         ├─ 产物存为 artifact
9
 └─ CD（持续交付/部署）
10
     └─ 部署到预发/生产（仅主干通过 CI 后）

阶段划分原则#

• 快反馈优先：lint/typecheck 放最前，几秒到一分钟出结果，别等 10 分钟构建完才告诉你格式错了。
• 失败即止：任一步红，后续不跑，省算力也快止损。
• 缓存：依赖（node_modules）、构建缓存命中能省大量时间。

关键纪律#

• 构建失败绝不上线：这是自动化里最不能妥协的一条。本博客的 deploy.sh 就遵循”先 git pull --ff-only → 构建 → 部署”，构建不过不部署。
• CD 只在受保护分支触发：feature 分支只跑 CI，主干合并才部署。
• 环境一致性：CI 用和本地一致的工具版本（通过 lockfile + 容器/指定 node 版本）。

小结#

• CI/CD = 提交即自动构建/测试/部署，移除人这个不稳定因素。
• 流水线：install → lint/typecheck/test → build → deploy。
• 快反馈前置、失败即止、依赖缓存。
• 铁律：构建失败不上线。

练习#

1. 画一张你项目的 CI 流程图，标注哪步失败会阻断合并。
2. 给流水线加”构建耗时”监控，识别最慢阶段能否缓存加速。
3. 解释为什么 lint 应排在 build 之前而非之后。