Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,102 +1,102 @@
|
||||
---
|
||||
title: "Deployment vs Release (部署与发布分离)"
|
||||
tags: [devops, continuous-delivery, feature-management, release-management]
|
||||
aliases: [Decoupled Deployment and Release]
|
||||
created: 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 级别恢复成为可能
|
||||
|
||||
## Sources
|
||||
|
||||
- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]
|
||||
---
|
||||
title: "Deployment vs Release (部署与发布分离)"
|
||||
tags: [devops, continuous-delivery, feature-management, release-management]
|
||||
aliases: [Decoupled Deployment and Release]
|
||||
created: 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 级别恢复成为可能
|
||||
|
||||
## Sources
|
||||
|
||||
- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]
|
||||
|
||||
Reference in New Issue
Block a user