{"name":"持续交付","id":"运维-持续交付","content":"# 持续交付\n\n> **持续交付（Continuous Delivery, CD）**是一种**以反馈控制为核心的软件系统演化范式**。\n> 它的目标是**更可靠、更可控地交付变更**。\n\n## 问题背景\n\n### CI 的边界\n\n持续集成（CI）解决了代码层面的集成问题——代码能编译、测试能通过、主干可构建。\n\n**但 CI 有盲区**：CI 通过 ≠ 代码能部署 ≠ 环境一致 ≠ 配置完整 ≠ 可交付。\n\n### 传统交付的三个反模式\n\n| 反模式 | 典型症状 |\n|--------|---------|\n| **手工部署** | 部署靠文档、结果靠运气、\"本地好使\" |\n| **后期才部署** | 运维首次接触在生产环境，协作如\"噩梦\" |\n| **生产手工配置** | 节点配置分化、环境不一致、无法回滚 |\n\n### 价值流断裂\n\n```\n开发完成 ≠ 可测试\n测试通过 ≠ 可部署\n部署成功 ≠ 可交付\n\n每一堵墙 → 等待积累 + 风险集中 + 问题滞后\n```\n\n### CD 的回答\n\n| CI 问 | CD 问 |\n|-------|-------|\n| 代码能集成吗？ | 代码能部署吗？ |\n| 代码能构建吗？ | 环境一致吗？ |\n| 测试能通过吗？ | 配置完整吗？ |\n| | 回滚可行吗？ |\n\n> **CI 解决\"代码能不能合\"，CD 解决\"代码能不能用\"。**\n\n## 持续交付的本质认知\n\n### 从自动化到系统反馈\n\n持续交付起源于持续集成（CI）的理念扩展，其演化路径如下：\n\n> 构建自动化 → 持续集成 → 持续交付 → 持续部署\n\n每一阶段都在回答同一个核心问题：\n\n> \"如何让软件变更成为**可验证的、可恢复的、可持续的过程**？\"\n\n持续交付的本质，是**在复杂系统中实现\"可控的变更传播\"与\"快速的反馈收敛\"。**\n\n### 反馈系统视角\n\n持续交付是一个**控制论闭环系统**：\n\n* **输入**：代码、配置、环境变更\n* **执行**：构建、测试、部署、验证\n* **反馈**：度量结果、监控信号、回滚机制\n* **调整**：流程优化、自动化改进、策略调整\n\n系统的稳定性依赖于反馈的**速度、精度、闭环性**。\n换言之，**交付系统的成熟度 = 学习速度**。\n\n## 持续交付的系统架构\n\n持续交付可视为一个多层控制系统，由三大\"控制面\"组成：\n\n| 控制面        | 目标      | 关键机制              |\n| ---------- | ------- | ----------------- |\n| **流水线控制面** | 规范化执行路径 | 构建 → 测试 → 部署 → 验证 |\n| **环境控制面**  | 管理执行上下文 | 环境即代码、可重建性、一致性    |\n| **配置控制面**  | 管理动态参数  | 配置中心、版本可追溯、运行时更新  |\n\n这三者共同构成\"交付控制系统\"，实现**从变更到反馈的闭环路径**。\n\n## 核心设计哲学\n\n### 质量左移（Shift Left）\n\n在软件生命周期的早期阶段尽可能发现问题。\n\n* 单元测试、静态检查、代码审查在提交前完成。\n* **原理**：问题越早被发现，修复成本越低。\n* **目标**：让\"反馈\"尽量靠近\"变更源头\"。\n\n### 单一可信源（Single Source of Truth）\n\n所有变更（代码、配置、环境）都必须被纳入统一的版本控制体系。\n\n* Git 既是代码仓库，也是系统状态的\"真相源\"。\n* **价值**：一致性、可恢复性、可追溯性。\n\n### 主干可发布（Trunk-Based Development）\n\n主干在任何时刻都应保持可部署状态。\n\n* 使用**功能开关**控制特性显隐。\n* **意义**：让发布成为\"自然状态\"，而非\"事件\"。\n\n### 可恢复性优先\n\n稳定系统的关键在于**恢复速度**而非**零故障**。\n\n* 提供版本、配置、数据的快速回滚机制。\n* **原则**：一切变更必须可撤销。\n\n### 坚持少做\n\n想做的事情永远超出交付能力，需聚焦真正高价值的工作。\n\n* **原理**：资源有限，只有聚焦才能产生突破\n\n### 持续分解问题\n\n将大问题拆解为可验证的小假设，降低不确定性。\n\n* **原理**：小步验证比大步冒险更可控\n* **实践**：用户故事拆解、技术方案分级\n\n### 坚持快速反馈\n\n以最短路径获取真实反馈，快速验证假设有效性。\n\n* **原理**：反馈越快，修正成本越低\n* **实践**：自动化测试、持续集成、短周期迭代\n\n### 持续改进并衡量\n\n基于数据驱动改进，建立度量驱动的反馈闭环。\n\n* **原理**：没有度量就没有改进\n* **实践**：DORA指标、交付周期监控\n\n> 持续交付的哲学可总结为：\n> **\"频繁发布不是冒险，而是风险分散。\"**\n\n## 核心工程实践\n\n### 分支与变更治理\n\n| 团队特征       | 适合策略                     | 核心目标   |\n| ---------- | ------------------------ | ------ |\n| 高成熟度、自动化完备 | 主干开发（Trunk）              | 最短反馈路径 |\n| 有发布周期、多人协作 | Git Flow                 | 稳定可控   |\n| 快速上线、持续部署  | GitHub Flow              | 实时集成   |\n| 多环境发布管理    | GitLab Flow              | 环境隔离   |\n| 多版本维护      | GitLab Flow with Release | 生命周期管理 |\n\n> 分支策略不只是版本管理问题，而是**变更风险暴露窗口的控制问题**，窗口越大，风险积累越多。\n\n**关键原则**：\n\n* **短生命周期分支**：减少合并延迟。\n* **功能开关治理**：将发布风险从合并时点推迟到启用时点。\n* **持续集成门禁**：确保主干稳定性。\n\n### 环境即代码（Environment as Code）\n\n**原则**：\n\n* 环境的定义、创建、销毁都应以代码形式存在。\n* 环境的差异应可追溯、可重建、可验证。\n\n**实现机制**：\n\n* **基础设施即代码（IaC）**：Terraform、Ansible、Pulumi\n* **容器化环境**：Docker、Kubernetes\n* **动态配置管理**：配置中心、Secrets 管理、版本标记\n\n**价值**：\n\n* 快速复制与回收环境\n* 一致性验证（Dev = Prod）\n* 提升可重复性与审计能力\n\n> \"环境即代码\"是持续交付的稳定支点，使系统具有\"可再生性\"。\n\n## 度量与反馈体系\n\n### 三类指标\n\n| 维度      | 指标             | 含义     |\n| ------- | -------------- | ------ |\n| **效率**  | 部署频率、前置时间、交付周期 | 系统反应速度 |\n| **质量**  | 故障率、修复时间、回滚率   | 系统稳定性  |\n| **成熟度** | 自动化率、覆盖率、环境一致性 | 系统可持续性 |\n\n### 指标解读模型\n\n* **效率 = 反馈速度**\n* **质量 = 反馈精度**\n* **成熟度 = 反馈闭环能力**\n\n持续交付的度量目标：为团队提供可靠的决策依据，支撑可预期的软件交付\n\n## 生态协同\n\n| 层级 | 范式 | 与 CD 的关系 |\n|-----|------|-------------|\n| 组织层 | DevOps | CD 是 DevOps 落地实践的技术载体，解决\"交付责任归属\"问题 |\n| 架构层 | 微服务 | CD 面临新挑战：多服务独立流水线的编排与一致性问题 |\n| 技术层 | 云原生 | 云原生为 CD 提供使能基础设施：环境标准化、不可变部署、声明式运维 |\n\n三者构成现代交付的\"组织-架构-技术\"协同闭环。\n\n## 结语\n\n持续交付的终极目标：\n**让软件交付成为一种可控的、可靠的、可重复的组织能力。**\n\n> 它将\"发布\"从一项风险事件，\n> 变为一种日常运营活动。\n\n## 关联内容（自动生成）\n\n- [/运维/持续集成.md](/运维/持续集成.md) CI 是 CD 的上游，CD 解决 CI 无法覆盖的交付层面问题（环境、配置、部署）\n- [/软件工程/DevOps.md](/软件工程/DevOps.md) CD 是 DevOps 落地的技术载体，DevOps 文化打破部门墙使 CD 得以贯通\n- [/运维/Docker.md](/运维/Docker.md) 容器化是环境一致性的保障基础，使\"构建一次，到处运行\"成为可能\n- [/软件工程/架构/系统设计/云原生.md](/软件工程/架构/系统设计/云原生.md) 云原生提供不可变部署和声明式运维，CD 是其落地的必由路径\n- [/运维/灰度发布.md](/运维/灰度发布.md) 灰度发布是 CD 后的流量控制手段，实现变更的渐进式披露\n- [/软件工程/微服务/微服务.md](/软件工程/微服务/微服务.md) 微服务将交付边界从单体变为服务矩阵，每服务独立流水线成为新挑战\n- [/软件工程/软件设计/代码质量/软件测试/软件测试.md](/软件工程/软件设计/代码质量/软件测试/软件测试.md) 自动化测试是 CD 质量门禁的核心，没有测试覆盖就没有 CD\n- [/软件工程/架构/系统设计/可观测性.md](/软件工程/架构/系统设计/可观测性.md) 可观测性为 CD 提供部署后的验证信号，是反馈闭环的关键节点\n- [/软件工程/质量工程.md](/软件工程/质量工程.md) CD 是质量工程在交付环节的实践，质量门禁是 CD 的核心机制\n- [/运维/SRE.md](/运维/SRE.md) SRE 追求的自动化运维与 CD 目标一致，SLO 是 CD 度量体系的组成部分\n- [/运维/K8s.md](/运维/K8s.md) K8s 为 CD 提供声明式部署能力，使\"git push 即上线\"成为工程实践\n- [/软件工程/架构/系统设计/监控系统设计.md](/软件工程/架构/系统设计/监控系统设计.md) 部署后监控验证变更有效性，是 CD 反馈闭环的最后一环\n- [/软件工程/架构/系统设计/混沌工程.md](/软件工程/架构/系统设计/混沌工程.md) 混沌工程验证 CD 的韧性假设，确保回滚机制真实有效\n- [/软件工程/架构/系统设计/网关.md](/软件工程/架构/系统设计/网关.md) 网关实现流量调度，支持蓝绿、金丝雀等 CD 发布策略\n- [/软件工程/架构/演进式架构.md](/软件工程/架构/演进式架构.md) 演进式架构的设计原则与 CD 的\"小步快跑\"理念高度一致\n","metadata":"tags: ['软件工程', '自动化', '计算机系统']","hasMoreCommit":true,"totalCommits":17,"commitList":[{"date":"2026-03-25T11:50:41+08:00","author":"MY","message":"docs(continuous-delivery): 重构持续交付文档结构并完善核心概念阐述","hash":"017e5c7d06828204821fe52e0e1afc33c0d7a6b9"},{"date":"2026-02-12T14:07:03+08:00","author":"MY","message":"doc: 整理标签","hash":"290b3e8ad18f48832ac282290238d020fc030a88"},{"date":"2026-02-10T11:32:53+08:00","author":"MY","message":"docs(运维): 更新持续交付文档添加标签和关联内容","hash":"67186151801d7a474ddd45d0e086521cd51981c9"},{"date":"2025-11-10T15:33:25+08:00","author":"MY","message":"docs(cd): 更新持续交付文档内容与结构","hash":"64eb09c0f7a30e22b0d5a14c4c9d90420250375a"},{"date":"2025-09-17T17:51:04+08:00","author":"MY","message":"docs: 用 Mermaid 重绘 git flow 图","hash":"e74f250a846a4d21abe64a045544b721d1605fb1"},{"date":"2024-09-13T20:25:19+08:00","author":"MY","message":"文档添加DevOps平台建设阶段及平台化实现详情","hash":"9aa5ce76e81b2d7730618af1e4c824fe8a9268f5"},{"date":"2024-09-11T18:57:55+08:00","author":"MY","message":"重构和更新运维和DevOps文档结构","hash":"94d46998574465d0498fa7d82cec759d0ee55857"},{"date":"2023-04-23T16:39:53+08:00","author":"MY","message":"✏持续交付","hash":"d9c07d6a5a452dec212c3873fa1205f7471d1fc5"},{"date":"2022-12-30T17:14:59+08:00","author":"cjiping","message":"✏️持续交付","hash":"8a45e65c39a825bc293068e642397567233a114f"},{"date":"2022-12-07T16:31:25+08:00","author":"cjiping","message":"✏️持续交付","hash":"d5c681b7e3f822906d16d2271e835eb3e944e287"}],"createTime":"2022-11-28T17:46:55+08:00"}