很多前端团队都知道要做 CI/CD，但一开始就容易走两个极端：
- 什么都没有，全靠手工发版
- 一口气堆一套很重的流水线，团队根本消化不了
真正适合大多数中小项目的，不是“最完整的 DevOps 体系”，而是一个能稳定跑起来的最小闭环。
如果你已经看过 代码质量门禁与 CI 集成、单元测试最佳实践、网页制作上线链路 和 Nuxt 生产环境部署指南，这篇会更聚焦到闭环搭法。
一、CI/CD 最小闭环的目标，不是炫技，而是降低发版风险
一个前端项目最小也要解决四件事：
- 代码合进来前能不能被检查
- 改动有没有预览环境
- 正式发布能不能重复执行
- 出问题能不能快速回滚
如果这四件事没有机制，发版就会越来越依赖“谁比较熟”。
二、先区分 CI 和 CD 各自解决什么问题
| 环节 | 主要作用 | 最低要求 |
|---|---|---|
| CI | 在合并前发现问题 | 构建、基础检查、关键测试 |
| CD | 把合格版本稳定发出去 | 预览、正式发布、回滚能力 |
很多团队会把两者混成一个概念，结果不是检查不够，就是发布链路不清晰。
三、对大多数前端项目，CI 先做到这 4 件事就够用了
- 安装依赖
- 运行构建
- 跑基础静态检查或类型检查
- 跑关键测试或最小回归验证
这四步并不复杂，但已经能挡住大量“本地好好的，线上挂了”的问题。
四、预览环境的价值，经常比自动正式发布更大
很多团队会急着做“自动发正式环境”，但实际上更实用的第一步往往是预览环境。
因为对产品、设计、运营来说，他们更需要：
- 在合并前看到真实页面
- 检查交互和文案
- 验证移动端和关键路径
没有预览环境，很多讨论只能靠截图和口头描述，返工成本会高很多。
五、回滚能力是闭环里最容易被忽视的一环
很多流水线只关注“怎么发”，却没有认真设计“怎么退”。
回滚至少要回答：
- 上一个稳定版本在哪里
- 回滚是重新部署旧版本，还是切换版本指针
- 回滚后要检查哪些核心页面
没有回滚思路的 CI/CD，本质上只是自动化部署，不是完整闭环。
六、失败案例：每次发布都自动成功，但线上问题越来越多
这类团队通常流程也不少：
- 自动构建
- 自动部署
- 甚至有一些测试
但问题在于：
- 没有针对关键业务路径的验证
- 没有预览给非开发角色确认
- 没有明确回滚动作
于是“能自动发”不等于“能稳定发”。
七、一个适合中小团队的最小 CI/CD 结构
| 阶段 | 做什么 | 结果 |
|---|---|---|
| 提交前 | 基础 lint / typecheck / 单测 | 先挡明显错误 |
| PR 阶段 | 自动构建 + 预览环境 | 大家能看真实页面 |
| 合并后 | 正式发布 | 发布流程标准化 |
| 发布后 | 核心页面检查 + 回滚准备 | 控制线上风险 |
八、检查清单
- 是否在合并前至少跑了构建和基础检查
- 是否为主要改动提供了预览环境
- 是否明确了正式发布的固定步骤
- 是否保留了上一个稳定版本用于回滚
- 发布后是否有最小人工验证清单
结语
前端项目做 CI/CD，不需要一开始就做得特别重。真正有效的是先搭出一个最小闭环：合并前能检查、合并后能发布、出问题能回滚。只要这三件事稳定下来，后续再加深自动化才有意义。
