跳到主要内容

Preview / Staging / Production 环境策略

CI / CD 真正开始复杂起来，通常不是从脚本数量开始，而是从环境开始。

很多前端项目一开始只有两种状态：

  • 本地
  • 线上

这样做在项目早期很省事，但一旦团队协作、PR 评审、联调、灰度、回滚这些问题变多，环境策略就会成为稳定性的关键。

先把三种环境分开​

Preview​

Preview 更像“这次改动的临时预览”。

它通常对应：

  • 一个 PR
  • 一次分支构建
  • 一个临时 URL

核心目标是：

  • 提前看界面
  • 让产品、设计、测试快速验收
  • 降低“代码合了才知道有问题”的概率

Staging​

Staging 更像“接近生产的预发环境”。

它通常会强调：

  • 和生产尽量接近的构建方式
  • 接近生产的环境变量
  • 接近生产的网关 / API / 数据结构

核心目标是：

  • 联调
  • 集成测试
  • 回归测试
  • 发布前验证

Production​

Production 就是真正面向用户的环境。

这里最重要的从来不是“自动化程度越高越好”，而是：

  • 发布可控
  • 回滚清楚
  • 权限明确
  • 故障影响面可管理

三种环境分别适合做什么​

环境核心目标更适合放什么
Preview看改动本身PR 预览、UI 验收、局部联调
Staging看系统整体回归测试、联调、发布前验证
Production面向真实用户正式发布、灰度、监控、回滚

Preview 环境最常见的价值​

Preview 对前端团队非常有用，原因很实际：

  • UI 改动不需要等合并后再看
  • 设计和产品可以直接点链接确认
  • 测试可以基于这次改动单独验证
  • 文案、布局、交互问题会更早暴露

Preview 更适合的特点​

  • 自动触发
  • 生命周期短
  • 跟 PR 或分支绑定
  • URL 独立
  • 适合频繁变动

Preview 不适合承载什么​

  • 生产级数据依赖
  • 高风险联调
  • 正式验收基线

Preview 更像“看这次改动”，不是“模拟整套系统上线之后会怎样”。

Staging 环境最常见的价值​

Staging 的核心不是“再来一个线上”，而是“在真正发生产之前，有一个更接近真实链路的地方先跑一遍”。

它通常适合：

  • 接三方服务联调
  • 跑 E2E
  • 做回归测试
  • 看构建产物在接近生产环境下是否正常
  • 验证环境变量、API 地址、网关、鉴权链路

Staging 最该接近生产的地方​

  • 构建命令
  • 打包产物
  • 环境变量结构
  • API 网关
  • 鉴权方式
  • 部署方式

如果 staging 和 production 差得太远，它的验证价值会迅速下降。

Production 环境更该看什么​

Production 不是“终于自动部署了”这么简单。

更关键的是：

  • 谁能发
  • 什么条件下能发
  • 发了之后怎么观察
  • 出问题怎么退

Production 常见保护项​

  • branch protection
  • environment approval
  • production secrets 单独隔离
  • 灰度或分批发布
  • 回滚入口明确

三套环境里的变量怎么管​

很多环境问题，最后不是代码错，而是变量错。

通常要至少分清：

  • 本地 .env.local
  • preview variables
  • staging variables
  • production variables

变量管理的常见原则​

  • 名称结构尽量一致
  • 值按环境分开
  • 生产密钥不要和其他环境混用
  • 能放 environment secrets 的，不要散在 workflow 里

域名和 URL 策略怎么定​

最常见的结构一般像这样：

  • preview-123.example.com
  • staging.example.com
  • www.example.com

或者：

  • 平台自动生成 preview URL
  • 固定 staging URL
  • 固定 production URL

前端比较要紧的是：

  • 回调域名
  • Cookie 域
  • CORS 白名单
  • 第三方 OAuth redirect URL

这些一旦忘了按环境拆开，预览环境和预发环境会很容易踩坑。

Preview 更适合自动，Production 更适合有保护​

这是比较稳的一条经验线。

Preview​

通常可以：

  • PR 创建就自动部署
  • PR 更新就自动刷新
  • PR 关闭就自动回收

Production​

通常更适合：

  • 合并主分支后再触发
  • 手动审批
  • 打 tag 或 release 再发
  • 需要环境保护规则

一个典型的工作流拆法​

可以把 workflow 拆成三类：

  • ci.yml：lint、typecheck、test、build
  • preview.yml：PR 预览环境
  • deploy.yml：staging / production 发布

这样比把所有逻辑堆进一份 YAML 更稳。

Preview 工作流更适合怎么做​

最常见的触发条件一般是：

  • pull_request

它的关键点通常是：

  • 产出一个独立 URL
  • 把链接回贴到 PR
  • 让每次 PR 更新都能自动刷新

Staging 工作流更适合怎么做​

Staging 常见触发条件是：

  • push 到 develop 或 release/*
  • workflow_dispatch

这样做的好处是：

  • 日常联调和回归有固定入口
  • 不会把每个 PR 的临时预览都混成一套长期环境

Production 工作流更适合怎么做​

Production 常见触发条件是：

  • push 到 main
  • 打 tag
  • workflow_dispatch

如果风险较高，更稳的方式通常是：

  • workflow_dispatch
  • 或合并后进入待审批环境

前端项目里更容易忽略的环境问题​

1. Preview 用的是 mock，Staging 才第一次接真接口​

这样很多联调问题会拖得太后。

2. Staging 和 Production 的构建命令不一样​

这会让“预发通过、线上翻车”变得很常见。

3. 第三方服务白名单没按环境拆​

比如：

  • OAuth 回调地址
  • 支付回调
  • 埋点域名
  • 图床域名

4. 生产环境回滚方案不清楚​

自动发布不是最大问题，发坏了以后怎么快速退，才是更值得先设计的事。

一个更实际的推荐策略​

小团队 / 小项目​

  • Preview：有
  • Staging：可选
  • Production：有保护

中型项目​

  • Preview：PR 自动部署
  • Staging：固定环境做联调和回归
  • Production：审批后发布

风险更高的项目​

  • Preview：给 UI 和局部验收
  • Staging：尽量接近生产
  • Production：灰度、监控、回滚都要明确

和 GitHub Actions 怎么配​

GitHub Actions 里的 environments 很适合接这层策略。

可以直接定义：

  • preview
  • staging
  • production

再分别挂：

  • secrets
  • variables
  • approval rules
  • deployment protection rules

这样 workflow 自己不用背所有差异，很多环境边界可以交给 GitHub 的环境模型去兜。

一个更实际的落地顺序​

  1. 先把 CI 跑稳
  2. 再补 Preview
  3. 再建 Staging
  4. 最后给 Production 加审批和回滚策略

如果一上来三套环境同时做，流程容易先变复杂，稳定性反而不会立刻变好。

参考来源​