Growth 全栈增长工程师指南：持续交付与持续部署的交付管道实战

• 教程

本文是《Growth：全栈增长工程师指南》中"持续交付"一节的深度展开。持续交付（Continuous Delivery）是一系列工具与实践的组合，它让软件在任何时刻都处于可部署的状态，是连接编码、测试与上线的关键一环。读完本文，你将理解持续交付的完整工作流、落地所需的本地开发环境/持续集成环境/测试环境三类基础设施，并掌握持续部署与持续交付的本质差异，以及它们与自动化部署、可配置性、持续集成之间的协作关系。

持续交付：让软件随时处于可交付状态

持续交付依赖于一系列的工具和实践，下图展示了一个典型的持续交付工作流：

这张图以**提交（Commit）**为起点，形成一个环形闭环：代码提交后依次经过自动化验收测试、探索性测试、用户验收测试（UAT）、预发布/准生产环境，最终到达生产环境；而生产环境的反馈监控（Feedback Monitoring）又回到提交环节，驱动下一次迭代。环上每一环都标注了典型的工具链，例如：

• Commit（代码提交）：构建、单元测试、代码指标、版本控制，关联 Git、JUnit、Maven、Nexus 等工具；
• 自动化验收测试：集成测试、冒烟测试、特性级测试、组件测试、服务虚拟化，关联 JUnit、Cucumber、SpecFlow 等；
• 探索性测试：UI 测试、可用性测试、手动测试，关联 Selenium 等；
• 用户验收测试（UAT）：演示、客户端主导的特性级测试、手动测试；
• Staging 与预生产：性能测试、网络测试、容量测试，关联 JMeter 等；
• 生产环境：部署后测试、持续在线事务测试、应用监控，关联 Jenkins、Docker、Chef 等。

也就是说，持续交付不只是"部署"这一个动作，而是一条覆盖构建、测试、发布、监控的完整流水线。

如果用一张更直观的三阶段图来概括这条流水线，可以理解为"持续集成 → 持续测试 → 持续部署"：

在这一工作流中，左侧开发者在各自机器上完成代码与单元测试，通过后进入集成单元测试与构建（核心特征是 Fast，快速）；中间阶段执行部署与冒烟测试（BVT），并展开回归、功能、系统、手动等端到端自动化测试；右侧所有测试通过后进入预发布部署与测试，再进入生产部署与验收，全程保持持续反馈（Constant Feedback）。

与开发无关，却决定交付成败的四项技能

原文特别强调，持续交付还依赖一系列与开发无关的技能：

1. 自动化——把重复的构建、测试、部署动作交给工具执行；
2. DevOps——打破开发与运维的边界，让团队对交付结果共同负责；
3. 云基础设施——弹性、可复现的运行环境是自动化部署的前提；
4. 以软件为中心的哲学——把环境、配置、流程本身当作软件来管理。

这四项能力决定了持续交付能否真正落地，也呼应了本仓库《Growth：全栈增长工程师指南》对全栈工程师的定义：不只精通某个领域，而是对系统有整体性的认识（参见 README.md）。

基础设施：让项目可以持续交付软件包

在让项目可以持续交付软件包之前，我们需要逐层搭建三类环境：本地开发环境、持续集成环境与测试环境。

本地开发环境：开发机器上的最小工具集

假设我们要开始一个 Java Web 项目，在开发机器上需要安装：

• 版本管理工具，如 Git，用于管理源代码；
• IDE，如 IntelliJ IDEA，用于搭建开发环境；
• 构建工具，如 Gradle，用于安装依赖、运行测试、构建工程；
• 语法检测工具，如 Checkstyle，用于检查代码风格与潜在语法问题；
• 单元测试框架，如 JUnit，用于进行单元测试；
• 集成测试框架，如 Cucumber、Selenium，用于做行为测试。

除了开发机器上的工具，项目代码里还必须有四类配套脚本与代码：

• CI 运行脚本：用于在 CI 上运行指定的测试；
• 上传包脚本：用于上传 build 完的软件包；
• 部署脚本：用于在本地把包部署到测试环境；
• 监控代码：用于监测网站性能和用户行为。

此外，还需要性能测试、网络测试等辅助测试工具来测试网站。这四类脚本正是交付管道的"最小可运行单元"——没有它们，CI 服务器即使拿到了源码也不知道该执行什么、产物该送去哪里。

持续集成环境：Master 与 Agent 的分工

要运行持续集成，我们需要一台运行持续集成服务器的机器。持续集成服务器由两部分组成：

• Master：一个用于控制其他运行持续集成服务的机器；
• Agent：执行指令的机器。

因此在 Agent 上需要安装对应的运行服务软件：

• 指定版本的语言环境，如 Java、Python；
• 构建工具；
• 版本管理工具，及对应的密钥（用于拉取私有仓库源码）；
• 打包工具，如 RPM；
• 虚拟桌面，即可以模拟桌面浏览器的软件（用于执行 Selenium 等 UI 测试）。

同时，我们还需要一个地方放置构建产物（如 RPM 包），即软件包仓库（Binary Repository）。这套 Master/Agent 架构在仓库的持续集成章节中有更详细的论述：以 Jenkins 为例，它基于 Java 开发，提供了用于监控持续重复工作的软件平台，让整个开发流程到部署都实现自动化。

测试环境：多环境隔离与差异化配置

相比前两个环境，测试环境要简单得多：我们只需要创建几个不同的环境——

• 开发者的测试环境；
• QA 环境；
• 模拟线上环境（Staging）。

这几个环境使用不同的配置。结合仓库中可配置章节的论述，典型的环境划分至少包括：

不同的环境最好独立写在不同的配置文件里，并以文件名区分，如开发环境用dev.config.js、测试环境用test.config.js；同时还需要一套变更控制机制，否则只有配置而没有运行机制，配置就形同虚设。更进一步，当应用运行在多个机器上时，修改配置要么选择热加载（不停机生效，但会持续消耗系统资源去读取、判断配置状态），要么选择冷启动配合自动化部署批量更新——而功能开关（Feature Toggle）则允许我们在上线新功能出现 Bug 时，通过切换开关而不是下线整个版本的方式来控制线上行为。

自动化部署：持续交付管道中的五步流水

持续交付的落地离不开自动化部署。仓库的自动化部署章节给出了一个五步流程，正好是持续交付管道中"构建 → 发布"环节的具体展开：

1. 获取源码：在 CI 服务器上使用git clone一类的方式获取源码（版本管理在前面章节已就绪）；
2. 获取依赖：无论是 Python、Ruby、Java 还是 JavaScript，都需要下载软件包依赖。由于我们依赖公有的包服务，系统会严重依赖于外部条件——原章节以 NPM 圈"left-pad 模块被作者撤下导致大量软件包挂掉"为例，说明自建包服务（如 Java 技术栈用 Nexus 搭建 Maven 私有服务）是一种简单有效的方案：代价是包可能不是最新的，但对追求稳定的项目而言这反而是优势；
3. 构建软件包：编译型语言会产出 Jar 这类压缩文档，但 Jar 无法直接安装使用，需要拷贝到服务器并修改配置。因此RPM/DEB 包是更好的选择——RPM 全称 Red Hat Package Manager（Red Hat 包管理器），工作于 Red Hat Linux 及其它 Linux 和 UNIX 系统。构建标准 RPM 包需要创建.spec文件，包含包的 Summary、Name、Version、Copyright、Vendor 等信息，然后执行rpmbuild命令生成目标 RPM 包；
4. 生成/上传安装包：生成软件包后上传到 Koji（Fedora 社区的编译系统）；
5. 目标平台安装/配置：如果已经对所有目标操作系统配置好软件源，就可以直接在服务器上用包管理工具安装，如yum install。

可见，持续交付的"最后一公里"——软件包的构建、归档、上传与安装——完全由这套自动化部署机制支撑。持续交付工作流之所以强调"随时可部署"，正是因为这些环节都已自动化、产物随时可被拉取。

与持续集成的关系：可部署的前提是可集成

持续交付并不孤立存在，它与仓库持续集成章节论述的实践互为表里。持续集成更关注代码质量：在每一次构建后运行单元测试，保证代码级的质量；单元测试的粒度则用来平衡持续集成的质量与速度。其核心价值在于：

1. 持续集成中的任何一个环节都是自动完成的，减少人工干预，节省时间、费用和工作量；
2. 保障每个时间点上团队成员提交的代码能成功集成，第一时间发现集成问题，使任意时间发布可部署的软件成为可能；
3. 利于软件本身的发展趋势，在需求不明确或频繁变更的情景中尤其重要，帮助团队有效决策并建立信心。

持续集成的流程中值得注意两点：

• 小步前进：集成越早问题越小。代码越早提交到源码服务器，别人就能越早与之集成。每天结束时本地修改要尽可能小，并且不破坏持续集成；要频繁在本地提交代码、编写独立的测试——如果最后才写测试，就会拖慢整个流程；
• 尽早反馈：反馈越早，问题越小。从 Code Review、静态代码分析、自动集成测试、自动验收测试到高频率发布，都是在做尽可能小的反馈，这是持续集成的基础，也是持续交付管道中每个环节自动化的意义所在。

持续部署：持续交付的进阶形态

在持续交付之外，还有持续部署（Continuous Deployment）——这更依赖于团队的组织结构。两者的对比如下图所示：

从上图可以清晰地看到：两者的前几个环节完全相同——单元测试（自动）、平台测试（自动）、交付至预发布（自动）、应用验收测试（自动）；唯一的分歧点在生产环节：

• 持续交付：部署到生产环境是手动触发的（Deploy To Production，Manual），部署后测试为自动；
• 持续部署：包括部署到生产在内的所有环节全部自动（Auto），代码通过所有测试后自动上线。

换言之，持续部署会直接将构建生成的包部署到产品环境。这意味着团队不仅要有强大的技术实力，也要有足够的组织支持——例如完善的自动化测试覆盖率、生产环境的监控与回滚能力，以及团队对"快速发布"的文化认同。这部分已经超出了软件开发本身的内容，但从持续集成到持续交付、再到持续部署，正是交付能力逐步升级的三级台阶：先保证可集成，再保证可交付，最终追求全自动上线。

小结

在《Growth：全栈增长工程师指南》的知识体系中，持续交付位于"上线"与"数据分析"之间的关键位置：它向上承接编码、构建、测试，向下支撑线上运行与反馈。回顾本章要点：

• 持续交付是一条覆盖提交、构建、测试、预发布、生产、监控的环形闭环工作流，由自动化、DevOps、云基础设施与以软件为中心的哲学共同支撑；
• 落地持续交付需要三类基础设施：本地开发环境（工具 + CI 脚本 + 部署脚本 + 监控代码）、持续集成环境（Master/Agent 分工，Agent 预装语言环境、构建工具、密钥、打包工具与虚拟桌面）、测试环境（开发、QA、Staging 多环境差异化配置）；
• 持续交付管道中的构建与发布环节，由自动化部署的五步流程（获取源码、获取依赖、构建软件包、上传安装包、安装配置）承载，并通过可配置机制保证不同环境各取所需；
• 持续部署是持续交付的进阶：当"部署到生产"也变为自动，交付能力才真正达到全自动化，而这需要技术与组织的双重支撑。

持续交付的本质，正如仓库 6.0.0 章节 所概括的那样：交付管道的建立和自动化是持续交付的基础。

• 教程