一、核心目标

实现更快、更可靠、低成本的自动化软件交付。通过增加反馈、改进开发人员、测试人员、运维人员和项目经理之间的协作，使软件始终处于可发布状态。

二、中心模式：部署流水线（Deployment Pipeline）

部署流水线是全书的核心机制，是应用程序从构建、部署、测试到发布整个过程的自动化实现。

工作方式

  • 应用程序的配置、源代码、环境或数据的每个变更都会触发创建一个新的流水线实例。
  • 流水线的首要步骤之一是创建二进制文件和安装包。
  • 后续是基于这些产物的一系列测试，用于证明其达到了发布质量。
  • 如果产物通过所有测试环节，即可发布。

三个目标

目标 说明
可见性 让软件构建、部署、测试和发布过程对所有人可见，促进合作
反馈 改善反馈，以便在整个过程中更早地发现并解决问题
自动化 使团队能够通过一个完全自动化的过程在任意环境上部署和发布软件的任意版本

三、八大原则

原则 内容
1. 可重复且可靠的发布过程 软件发布应是一个简单、可重复执行的过程，通过在发布前对每个环境进行多次测试来确保可靠性
2. 将几乎所有事情自动化 构建、部署、测试和发布流程应尽可能自动化，仅在需要人做决定前保留必要的人工环节
3. 把所有东西纳入版本控制 源代码、配置信息、环境脚本、数据库脚本、依赖库、工具链、技术文档等全部纳入版本控制
4. 提前并频繁地做让你感到痛苦的事 如果集成痛苦，就每次提交后立即集成；如果发布痛苦，就每次提交后尝试发布到类生产环境
5. 内建质量 越早发现缺陷，修复成本越低。测试不是开发结束后的阶段，交付团队每个人都对质量负责
6. "DONE"意味着"已发布" 一个特性只有交到用户手中才能算完成，没有"已经完成了80%"这种说法
7. 交付过程是每个成员的责任 开发、测试、运维等角色需打破壁垒，共同对交付负责
8. 持续改进 定期召开回顾会议，反思做得好与不好的方面，每个改进点需有人负责跟踪执行

四、核心实践

实践 说明
只构建一次二进制文件 构建产物一旦生成，在后续所有环境中复用，不在每个环境重新构建
以相同方式部署到每个环境 使用同一套自动化脚本部署到开发、测试、预发布、生产环境，确保一致性
对部署进行冒烟测试 部署完成后立即运行基本验证，确认系统可用
保持环境相似 各类环境（开发、测试、生产）应尽可能一致，减少环境差异导致的问题
失败即停止生产线 流水线中任何环节失败，立即停止后续步骤，优先修复问题
持续集成 每个人都向主干频繁提交代码，每次提交触发自动化构建和测试
功能开关 将未完成的功能放入主干但对用户不可见，使主干始终保持可发布状态
抽象分支 通过抽象来模拟分支，对代码库进行大范围变更而不破坏主干稳定性

五、三类发布反模式

反模式 表现
手工部署软件 依赖人工执行部署步骤，不可重复、易出错、无法审计
开发完成后才向类生产环境部署 直到发布前才发现环境差异导致的问题，修复成本极高
生产环境的手工配置管理 配置依赖临时手工操作，缺乏版本控制和可追溯性

六、软件交付的四个组成部分

任何可工作的软件系统都包含以下四个部分，持续交付要求对这四部分进行全面控制：

  1. 可执行的代码
  2. 配置信息
  3. 运行环境
  4. 数据

所有变更（包括配置、环境、数据）都应触发部署流水线进行验证。

七、测试体系

部署流水线中的测试分为两类：

类型 内容
业务面向的测试 单元测试、集成测试、系统测试、功能验收测试
技术面向的测试 非功能验收测试，包括性能、容量、安全性、可扩展性等

八、与 DevOps 的关系

持续交付是 DevOps 运动的核心实践之一。DevOps 的概念向外延伸至运营、用户及快速反馈机制等内容，而持续交付聚焦于软件从开发到发布的工程实践层面，为 DevOps 提供了具体的技术实现路径。