Release 策略与渐进发布：semver、蓝绿、金丝雀与回滚

0. 元信息

• 主题路径：docs/topics/ci-cd-and-release/subtopics/release-strategies-and-rollout/README.md
• 主分类：工程技术
• 辅助分类：安全与可靠性
• 适合对象：已经能跑通 CI pipeline，想把发布变成「可回滚、可灰度」的开发者
• 建议周期：5～8 天，每天 1.5～2 小时
• 前置知识：pipeline-and-automation
• 最终目标：能独立选择发布策略、写 Argo Rollouts canary / blue-green 步骤、配 AnalysisTemplate 指标门控、设计 feature flag 切换与回滚预案

1. 学习路线

semver + conventional commits + release-please
  → tag、release branch、changelog
  → 蓝绿 / 滚动 / 金丝雀策略对比
  → Argo Rollouts Canary 步骤 + AnalysisTemplate
  → Flagger metric provider
  → feature flag（LaunchDarkly / Unleash / OpenFeature）
  → 回滚预案：revert / switch / abort

2. 阶段周数分配

精简子主题不固定周数。按概念、正常路径、失败路径、综合实验四段推进，共 5～8 天。

3. 九阶段表

4. 第一周任务

精简子主题省略逐日表。每天只引入一个变量；先跑正常路径，再做四类失败实验。Day 1 必须明确 semver 规则与 release branch 命名。

5. 阶段通用验收

采用父主题 §5；本页额外要求保存策略对比表、canary YAML、AnalysisTemplate、feature flag 配置、回滚演练记录与清理命令。

6. 最终验收

完成 1 份策略对比表、1 段 Argo Rollouts Canary YAML（带 AnalysisTemplate）、1 个 feature flag 集成、至少 4 类失败实验、1 次完整回滚演练，并用 10 分钟解释策略选择与回滚路径。

7. 综合项目

把本页产出合入父主题首选项目：GitHub Actions → GHCR → k8s Argo Rollouts 金丝雀发布全链路。单独交付时，提供 Rollout manifest、AnalysisTemplate、release-please 配置、notes/retrospective.md。

本主题贡献

本主题把 release 当成可灰度可回滚的工程：semver 语义化版本、Argo Rollouts canary 步骤、AnalysisTemplate 指标门控、blue-green 流量切换与 feature flag 部署/发布解耦，5 分钟内能定位上一稳定版本。

职责（3 项）

1. 用 semver + Conventional Commits + release-please 自动 bump 与 changelog，能解释 1.2.3-rc.1 < 1.2.3、1.2.3+build.4 build metadata 不污染语义、force-with-lease 签 tag 防覆盖、Monorepo 怎么独立 bump 子包版本；
2. 设计 Argo Rollouts Canary 步骤（setWeight: 10 → pause: 5m → setWeight: 50 → pause → setWeight: 100）+ AnalysisTemplate 接 Prometheus 指标（错误率/P99/saturation），能解释 failureThreshold + abort 的门控边界，以及 metric provider 不可达时悄悄跑满 100% 的危险；
3. 设计 blue-green 切换（旧版本一直保留、switch 即回滚）、canary 回滚（abort / rollback 步骤）、feature flag 切换（flag flip 1 秒生效、无 deploy）三条回滚路径，能解释 deploy vs release 的解耦原则。

交付物（4 项）

1. Argo Rollouts Canary YAML（带 trafficRouting、steps、analysis），含 setWeight + pause 步骤注释；
2. AnalysisTemplate（错误率 > 5% 自动 abort）+ AnalysisRun 报告，metric provider = Prometheus；
3. release-please 配置（Conventional Commits → 自动 PR → 自动 changelog）+ semver bump 脚本；
4. feature flag 集成（OpenFeature SDK / LaunchDarkly / Unleash 任一）+ 回滚预案（revert / blue-green switch / canary abort / flag off 五段）。

指标（3 项）

1. canary abort 触发率 ≤ 5%（promote 100% 之前出错能自动回滚）；
2. release rollback MTTR ≤ 5 分钟（git revert / Rollout undo / feature flag off 任一路径）；
3. feature flag 清理周期 ≤ 30 天（CI 检查无主 flag + 到期日）。

8. 推荐开源资料

Argo Rollouts（Apache-2.0）作渐进发布主线；Flagger（Apache-2.0）作对照；Spinnaker（Apache-2.0）作多云；release-please（Apache-2.0）作版本自动化；semantic-release（MIT）作 JS 生态对照；LaunchDarkly / Unleash 文档作 feature flag；OpenFeature（Apache-2.0）作 vendor-neutral 抽象。复制前核对当前 LICENSE。

9. 学习资料汇聚（v0.3 自包含）

9.1 背景与动机

Release 策略决定爆炸半径与回滚代价。蓝绿：两套环境切换，秒级回滚；滚动：批次替换，零停机但回滚慢；金丝雀：按流量百分比切换，metric-driven 回滚；feature flag：发布与部署解耦，runtime 切换。

Jez Humble 和 David Farley 在《Continuous Delivery》里把「部署与发布解耦」作为关键原则。Eric Ries 在 Lean Startup 里强调小可行发布（MVPS）。今天的 Argo Rollouts、Flagger、Spinnaker 把这些想法工程化。

我们这一节要解决一个具体问题：CI 出可签名制品后，怎么把它安全地送到生产，遇到事故能在 5 分钟内回滚。

9.2 概念地图

flowchart LR
  Tag[git tag / release branch] --> Release[release pipeline]
  Release --> Strategy{strategy}
  Strategy --> BlueGreen[blue-green: switch]
  Strategy --> Rolling[rolling: replace batch]
  Strategy --> Canary[canary: weight + metric]
  Strategy --> Flag[feature flag: runtime]
  Canary --> Analysis[AnalysisTemplate]
  Analysis --> Metric[Prometheus / Datadog]
  Metric --> Decision{pass?}
  Decision -- yes --> Promote[promote 100%]
  Decision -- no --> Abort[abort / rollback]
  Flag -.runtime toggle.-> Promote
  Promote --> Observability[DORA / audit]
  Abort --> Observability

核心关系：release 决定版本与时机，策略决定流量分配，metric 决定是否继续，feature flag 决定行为可见性。四个维度必须配合。

9.3 基础知识讲解

9.3.1 论文 / 规范

9.3.2 书

9.3.3 博客 / 文档

9.3.4 人物

9.3.5 方法

9.4 经典问题与经典案例

9.5 学习难点

概念难点

思维难点

工程难点

9.6 技术标准与接口

9.6.1 Entity

9.6.2 Scope

Argo Rollouts 在 Kubernetes 上提供 canary / blue-green；Flagger 依赖 service mesh（Istio / NGINX）做 metric gating；Spinnaker 是多云发布平台；release-please / semantic-release 自动 bump 与 changelog；feature flag 把发布与部署解耦。

9.6.3 Structure

Argo Rollouts CRD：Rollout（strategy + steps + trafficRouting）、AnalysisTemplate（metrics + thresholds）、AnalysisRun（单次执行）。Flagger CRD：Canary（provider + metrics）。Spinnaker pipeline：stages 序列。feature flag SDK：client + context + variation。

9.6.4 Ecosystem

Argo Rollouts 与 Argo CD 集成；Flagger 集成 Flux / Helm operator；Spinnaker 独立多云；release-please 与 GitHub Actions / release-please-action 集成；OpenFeature 提供 .NET / Go / Java / Node / Python SDK。

9.6.5 Depth Tiers

本子主题目标是 L3。

9.6.6 Source

• Argo Rollouts 文档
• Flagger 文档
• Spinnaker 文档
• semver.org
• Conventional Commits
• release-please
• OpenFeature
• 引用版本快照日期：2026-07-30；实作前运行 kubectl version、argocd version。

10. 常见误区

• 把 release branch 当 long-lived；
• tag 不签名 / 允许 force push；
• canary 跑完 100% 才报警；
• metric provider 不可用，悄悄跑满 100%；
• feature flag 没有到期日，技术债堆积；
• flag 切完没清理，半年后没人记得；
• abort 触发但没人接 alert；
• 蓝绿切完不保留旧版本；
• 回滚预案只在文档里，没演练；
• 用 1.0.0 但 API 已经破坏兼容；
• prerelease 被当 stable 推；
• 滚动升级失败 rollback 不验证。

11. 所有知识点分类（统一规则）

1. 编程语言；2. 数据结构与算法；3. 计算机基础；4. 工程技术；5. Web 与后端；6. 前端与客户端；7. 数据与人工智能；8. 项目与职业能力；9. 安全与可靠性。

本计划归属：工程技术 主 + 安全与可靠性 辅。