3.8 KiB
3.8 KiB
title, tags, aliases, created
| title | tags | aliases | created | |||||
|---|---|---|---|---|---|---|---|---|
| Deployment vs Release (部署与发布分离) |
|
|
2026-04-25 |
Deployment vs Release (部署与发布分离)
Deployment vs. Release 是 Feature Flag 实现的核心理念：代码部署（Deploy）到生产环境，与功能对用户可见（Release），是两个独立的事件。
Definition
"Traditional deployments are all-or-nothing: you push code and everyone gets it immediately. This is why deployments are scary and why teams deploy at 2 AM 'just in case.'"
"Deploy whenever you want, release when you're ready."
Aliases
- Decoupled Deployment and Release
- 部署发布分离
核心对比
| 维度 | 传统方式（部署=发布） | Feature Flag（部署≠发布） |
|---|---|---|
| 代码到达生产 | 与用户可见同步 | 提前到达，用户不可见 |
| 回滚能力 | 需要重新部署 | 配置变更，秒级 |
| 发布时机 | 必须与部署同步 | 任意时刻可发布 |
| 团队压力 | 2AM 部署"以防万一" | 白天从容发布 |
| 实验能力 | 低（全量或无） | 高（灰度、可控放量） |
生命周期对比
传统方式
开发 → 测试 → 合并 → 部署 → 发布（全量）
↑
部署=发布
Feature Flag 方式
开发 → 测试 → 合并 → 部署 → 发布控制 → 渐进放量
↑ ↑
代码到达 用户可见
生产环境 由开关控制
关键价值
1. 降低部署风险
"Feature flags change this. You can deploy code to production without releasing it to users."
代码可以在生产环境中就绪，但功能对用户保持隐藏，直到团队确认质量。
2. 加速交付
团队不再需要等待"完美时机"发布功能。代码就绪即可部署，功能发布由业务决定。
3. 赋能团队
- 产品：随时决定发布节奏
- 工程：随时部署，无需等待发布窗口
- 运营：渐进放量，数据驱动决策
4. 重新定义 RTO
当部署≠发布时，恢复（Rollback）不再是回滚部署，而是关闭 Feature Flag。
与 CI-CD-Pipeline 的关系
部署与发布的分离重构了 CI/CD 流程：
| 阶段 | 传统 CI/CD | Decoupled CI/CD |
|---|---|---|
| Build | 构建产物 | 构建产物 |
| Test | 单元/集成测试 | 单元/集成测试 |
| Deploy | 部署到 prod | 部署到 prod（用户不可见） |
| Release | — | Feature Flag 控制 |
| Monitor | 部署后监控 | 渐进放量期间监控 |
| Rollback | 重新部署旧版本 | 关闭 Feature Flag |
风险模型转变
| 维度 | 传统模型 | Decoupled 模型 |
|---|---|---|
| 风险集中点 | 部署时刻 | 功能发布时刻 |
| 风险暴露范围 | 全量用户 | 当前放量比例 |
| 应急响应 | 小时级回滚 | 秒级开关 |
| 团队心态 | 防御性（害怕部署） | 进攻性（敢于实验） |
Related Concepts
- Feature Flag — 实现部署与发布分离的核心机制
- CI-CD-Pipeline — Decoupled Deployment 是现代 CI/CD 的重要理念
- Progressive Rollout — 部署与发布分离使渐进放量成为可能
- Kill Switch — 发布控制权的极端体现（紧急关闭）
- RTO — 部署与发布分离将 RTO 从部署回滚转向配置变更
- Micro-Recovery — 部署与发布分离使 feature 级别恢复成为可能