CI/CD 与发布：从流水线到灰度与回滚

0. 元信息

• 主题路径：docs/topics/ci-cd-and-release/README.md
• 主分类：工程技术
• 辅助分类：安全与可靠性
• 适合对象：写过 Dockerfile、能用 Git 协作、想把代码从 push 到生产全链路打通的后端/SRE/DevOps 工程师
• 建议周期：4～6 周，每周 8～12 小时（含至少一半时间搭真实流水线、做一次完整 canary + 回滚演练）
• 前置知识：git-and-collaboration、docker-basics、rest-api-design；会读 YAML、写 shell、看 kubectl 输出
• 最终目标：能独立设计 CI 流水线（构建/测试/扫描/产物上传），选择 CD 策略（蓝绿/金丝雀/滚动/灰度），用 IaC + GitOps 把多环境管起来，用 DORA Four Keys 度量团队交付能力，事故出现时按预案回滚

1. 学习路线

流水线核心（GitHub Actions / GitLab CI / CircleCI）
  → 制品、缓存、矩阵、self-hosted runner
  → semver、tag、release branch、changelog
  → CD 策略：蓝绿 / 滚动 / 金丝雀 / 灰度
  → feature flag、Argo Rollouts、Flagger、Spinnaker
  → IaC：Terraform / Pulumi / Ansible
  → GitOps：Argo CD / Flux、drift 检测、多环境
  → DORA Four Keys、SBOM、SLSA、签名、审计
  → 回滚预案、incident response、综合项目

按代码从 commit 到生产这条链学。每一步都跑真实流水线或部署真实环境，先证据后结论。

2. 阶段周数分配

4 周方案对应每天满负荷；6 周方案多出的时间用来重做实验和制造故障，不用来囤课。

3. 九阶段表

关键陷阱有四个：流水线只跑 happy path；用 latest tag 部署；CD 策略选错爆炸半径太大；只看部署成功，不看 DORA 数据。

4. 第一周任务

Day 1 运行约定：使用 GitHub Actions（免费额度 2000 分钟/月，公开仓库无限）；记录 gh --version、act --version（本地 runner）、kubectl version、docker version、terraform version。所有命令记录 commit SHA、runner label、时间戳。回滚演练前先在 staging 跑一次。

5. 阶段通用验收

1. 不看答案独立写一条 GitHub Actions workflow；
2. 用自己的话解释 CI/CD 关键概念（jobs/steps、artifact、cache、matrix、runner、OIDC）；
3. 画一张图：commit → CI → registry → CD → 环境 → 监控；
4. 测试正常、测试失败、scan 失败、push 失败、deploy 失败、回滚六类路径；
5. 至少准备 3 个真实仓库并贴出实际 workflow run 链接；
6. 记录 DORA Four Keys（部署频率、变更前置时间、变更失败率、失败恢复时间）；
7. 能修改既有流水线（加 stage、修 cache、加 secret 旋转），而不是只能照抄。

6. 最终验收

• 独立设计 CI 流水线（构建/测试/扫描/产物上传）并落地；
• 至少完成 18 个真实 workflow run（4 类失败 + 14 类成功）；
• 制造并定位至少 8 类事故：cache miss 导致 build 慢、并发超过 256、OIDC 配错、canary 指标不达标、drift 检测报警、签名验证失败、tag 冲突、镜像被覆盖；
• 完成 1 个综合项目：GitHub Actions → GHCR → k8s Argo Rollouts 金丝雀全链路，交付 workflow、Rollout manifest、Dashboard 截图、回滚记录与 notes/retrospective.md；
• 能用 15 分钟讲清从 commit 到生产的全链路，以及 DORA Four Keys 怎么采。

7. 综合项目

首选：为一个真实 Web 应用搭建 GitHub Actions → GHCR → k8s Argo Rollouts 金丝雀发布全链路。

必须包含：workflow（on push / on tag / merge queue）、multi-stage build、image 扫描（trivy / cosign）、SBOM 输出、GHCR 推送（OIDC）、k8s manifest、Argo Rollouts Canary 步骤（含 AnalysisTemplate 用 Prometheus 指标门控）、自动回滚、merge queue、Dashboard（Grafana）四指标。

备选：把现有手动发布流程重构为 GitOps（Argo CD + IaC）。

把现有应用从 kubectl apply / 脚本部署改成 Application + GitRepository 模式，配 Terraform 管云资源、Helm 管 k8s 资源，实现 push-to-deploy 与 drift 检测。

任何项目都需包含：

1. 需求与成功标准（DORA 指标目标）；
2. 流水线拓扑、Runner 与 cache 选择理由；
3. 关键 YAML（workflow、Rollout、Application）；
4. 模块化源码或 manifest；
5. 正常/失败/回滚测试；
6. 环境、权限、清理和脱敏说明；
7. README + Dashboard + 原始证据索引；
8. retrospective（用时、难点、收获、下一步）。

8. 推荐开源资料

默认顺序：先跑通一条 happy path → 加失败注入 → 加 cache/matrix → 拆 CD 策略 → 上 GitOps → 上签名/SBOM → 出 DORA 卡。

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

本节由本计划生成。链接指向原始材料或作者公开内容。标准会更新，实验记录必须写明版本和日期。

9.1 背景与动机

CI/CD 不是工具集，是工程纪律。它回答一个老问题：怎么让代码变更以可预测、低风险、可回滚的方式持续流到生产。

1990 年代之前，软件以季度/年度发布。Jez Humble 和 David Farley 在《Continuous Delivery》一书中提出「部署流水线」概念：build → test → deploy 是一条单一路径，每一步都有自动验证和回滚手段。Eric Ries 的《The Lean Startup》同期把 build-measure-learn 循环搬到软件交付上，强调 MVPS（小可行发布）。

2010 年代后，DORA（Dora DevOps Research and Assessment）开始量化交付能力：DORA Four Keys（部署频率、变更前置时间、变更失败率、失败恢复时间）。Forsgren、Humble、Kim 在 Accelerate 中用四年统计把 DORA 与组织绩效绑死，今天几乎所有工程效能报告都会引这四个数字。

今天这条链上的工具组合通常是：GitHub Actions / GitLab CI 做 CI；Argo CD / Flux 做 GitOps；Argo Rollouts / Flagger / Spinnaker 做渐进式发布；Terraform / Pulumi 做云资源 IaC；Sigstore / SLSA 做供应链签名；Prometheus / Grafana 做 DORA 看板。学习 CI/CD 的价值不在于记住某个工具的 YAML，而在理解「让变更持续安全地流向生产」这件事的全链路权衡。

9.2 概念地图

flowchart LR
  Commit[commit / merge queue] --> CI[CI runner]
  CI --> Build[build / multi-stage]
  Build --> Test[unit / integration]
  Test --> Scan[scan / SBOM]
  Scan --> Sign[cosign sign]
  Sign --> Registry[OCI registry]
  Registry --> CD[CD controller]
  CD --> Strategy{release strategy}
  Strategy --> BlueGreen[blue-green]
  Strategy --> Rolling[rolling]
  Strategy --> Canary[canary / Argo Rollouts]
  CD --> IaC[Terraform / Pulumi]
  CD --> GitOps[Argo CD / Flux]
  Canary --> Metrics[Prometheus gate]
  Canary --> Flag[feature flag]
  Metrics --> Decision{abort?}
  Decision -- yes --> Rollback[rollback]
  Decision -- no --> Promote[promote]
  Promote --> Observability[DORA / audit log]
  Observability -.反馈.-> CI

核心关系：commit 触发 CI；CI 产出可签名、可扫描的 OCI 制品；CD controller（Argo CD / Rollouts）按策略分发到目标环境；策略选择决定回滚代价；指标、feature flag、审计日志形成反馈环，反过来影响下次发布的策略与质量门。

9.3 基础知识讲解

9.3.1 经典论文 / 规范

9.3.2 经典书籍

备查：Kim 等的 The DevOps Handbook；Vernon, Implementing Domain-Driven Design（DDD 与发布边界）。

9.3.3 优秀博客 / 文档

9.3.4 核心人物

9.3.5 开发方法

9.4 经典问题与经典案例

9.5 学习难点

概念难点

思维难点

工程难点

9.6 技术标准与接口

9.6.1 Entity

9.6.2 Scope

• CI（GitHub Actions / GitLab CI / CircleCI）负责构建、测试、扫描、出制品。
• CD controller（Argo CD / Flux）按 Git 期望状态收敛集群。
• 渐进发布器（Argo Rollouts / Flagger / Spinnaker）在 controller 上加策略层。
• IaC（Terraform / Pulumi / Ansible）管云资源。
• 签名 / SBOM（cosign / SLSA / in-toto）管供应链完整性。
• 可观测（Prometheus / Grafana / OTel）出 DORA 卡。
• 它们之间用 OCI registry、OIDC、Kubernetes API 互通。

9.6.3 Structure

• workflow YAML：on / jobs / steps / uses / run / env / with / needs / matrix / concurrency。
• 必须掌握字段：on.push.branches、on.workflow_dispatch、jobs.<id>.runs-on、jobs.<id>.steps[*].uses / run、permissions、secrets、matrix.include / exclude、needs。
• 必须掌握接口：actions/checkout@v4、actions/setup-go@v5、docker/build-push-action@v6、aquasecurity/trivy-action、sigstore/cosign-installer、Argo Rollouts CRD（Rollout / AnalysisTemplate / AnalysisRun）、Argo CD CRD（Application / AppProject）、Terraform CLI（init/plan/apply/import/state）、kubectl rollout status / undo、gh workflow run。
• 必须掌握的方法：读 Actions 表达式语法、写 AnalysisTemplate 指标、写 Terraform module + remote state、用 cosign verify-blob / verify-image、从 GitHub API + Prometheus 拉 DORA 数据。

9.6.4 Ecosystem

• CI：GitHub Actions、GitLab CI、CircleCI、Jenkins（legacy）、Buildkite、Drone、Woodpecker。
• CD controller：Argo CD、Flux、Spinnaker、Jenkins X。
• 渐进发布：Argo Rollouts、Flagger、Spinnaker、LaunchDarkly 自动发布、Datadog Continuous Testing。
• IaC：Terraform、Pulumi、Ansible、Crossplane、OpenTofu（fork）。
• 签名 / SBOM：cosign、SLSA Toolkit、in-toto、SPDX、CycloneDX。
• 可观测 / DORA：Prometheus、Grafana、Datadog、Honeycomb、LinearB、Waydev。
• 事实标准 vs 标准本身：OIDC 是标准；OIDC 在不同云的 trust policy 实现各异；OCI Distribution Spec 是标准；不同 registry 实现的功能（cosign 兼容、签名验证、garbage collection）差异显著。

9.6.5 Depth Tiers

本父主题目标是 L3。自定义 controller 或跨云 IaC 可触及局部 L4，但不作为 4～6 周硬门槛。

9.6.6 Source

• GitHub Actions 文档 — workflow、OIDC、security hardening。
• Argo Rollouts 文档 — Canary / BlueGreen / AnalysisTemplate。
• Argo CD 文档 — Application / AppProject / sync。
• Terraform 文档 — state、module、import。
• Sigstore cosign — sign / verify-blob / verify-image。
• DORA Four Keys 指南 — 四指标采集。
• SLSA v1.0 — 供应链等级模型。
• 引用版本快照日期：2026-07-30；实作前运行 gh --version、kubectl version、terraform version。

10. 常见误区

• 把 CI/CD 当成「装个 Jenkins」；
• 直接 push 到 main 就触发 deploy，没有 review、没有 staging；
• 用 latest tag 部署；
• pipeline 不区分 build / test / scan / deploy，全堆在一个 job；
• 缓存 key 用 *，每次都失效；
• 用 long-lived AWS access key 当 secret；
• 不限制 permissions，默认 write-all；
• CD 用 kubectl apply -f，没有 GitOps 与 drift 检测；
• canary 配了，但 metric provider 不可用，悄悄跑满 100%；
• 灰度只看版本号，不看用户维度（feature flag）；
• 没有 DORA 数据，季度复盘全凭感觉；
• 没有 on-call，事故出现找不到人；
• 不写 postmortem，或 postmortem 只写「我们做错了」；
• 用同一个 chart / manifest 覆盖多环境，只换 namespace；
• Terraform state 提交到 Git，并发 plan 直接损坏；
• Helm chart 升完不验证 rollback；
• cosign 签了制品，但 verify 没在 deploy pipeline 跑；
• 把 audit log 当 logrotate 对象，定期清理；
• 演练只在 staging 跑一次，再也没复盘。

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

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

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