更大的格局：持续交付

能够构建源代码只是软件交付过程的一方面。更重要的是，您希望将产品发布到生产环境以提供业务价值。在此过程中，您需要运行测试、构建发行版、出于质量控制目的分析代码、可能配置目标环境并部署到该环境。

整个过程自动化有很多好处。首先也是最重要的一点是，手动交付软件速度缓慢、容易出错且令人伤脑筋。我确信我们每个人都讨厌由于部署错误而度过的漫漫长夜。随着敏捷方法的兴起，开发团队能够更快地交付软件。两到三周的发布周期已成为常态。 Etsy 和 Flickr 等一些组织甚至每天多次将代码交付生产！最理想的情况是，您希望能够通过按下按钮来选择目标环境来发布软件。自动化测试、CI 和部署等实践融入了持续交付的一般概念。

在本书中，我们将了解 Gradle 如何帮助您的项目从构建到部署。它将使您能够自动执行实施持续交付所需的许多任务，无论是编译源代码、部署可交付成果，还是调用帮助您实施流程的外部工具。要深入了解持续交付及其所有方面，我推荐 Jez Humble 和 David Farley 撰写的《持续交付：通过构建、测试和部署自动化实现可靠的软件发布》（Addison Wesley，2010 年）。

自动化项目从构建到部署的过程

持续交付引入了部署管道的概念，也称为构建管道。部署管道代表将软件从版本控制转移到生产环境的过程的技术实现。该过程由多个阶段组成，如图2.7所示。

Figure 1. 图 2.7 部署管道的阶段

提交阶段：有关项目技术健康水平的报告。此阶段的主要利益相关者是开发团队，因为它提供有关损坏代码的反馈并发现 “代码异味”。此阶段的工作是编译代码、运行测试、执行代码分析和准备分发。
自动验收测试阶段：断言通过运行自动测试来满足功能和非功能要求。
手动测试阶段：验证系统是否在测试环境中实际可用。通常，此阶段涉及 QA 人员来验证用户故事或用例级别的需求。
发布阶段：将软件作为打包发行版交付给最终用户或将其部署到生产环境。

让我们看看部署管道的哪些阶段可以从项目自动化中受益。显然，手动测试阶段可以排除在进一步讨论之外，因为它只涉及手动任务。本书主要关注在提交和自动化验收测试阶段使用 Gradle。我们要研究的具体任务是

编译代码
运行单元和集成测试
执行静态代码分析并生成测试覆盖率
创建发行版
配置目标环境
部署可交付成果
执行冒烟测试和自动化功能测试

图 2.8 显示了每个阶段中的任务顺序。虽然没有硬性规则阻止您跳过特定任务，但建议您遵循顺序。例如，您可以决定编译代码、创建发行版并将其部署到目标环境，而无需运行任何测试或静态代码分析。然而，这样做会增加未检测到的代码缺陷和代码质量差的风险。

Figure 2. 图 2.8 构建管道阶段执行的任务

基础设施配置、自动化部署和冒烟测试等主题也可以应用于发布阶段。实际上，将这些技术应用于生产环境比在受控测试环境中更为复杂。在生产环境中，您可能必须处理集群和分布式服务器基础设施、零停机版本部署以及自动回滚到先前版本的问题。

涵盖这些高级主题超出了本书的范围。不过，有一些部署管理工具的优秀示例，你可以去看看，比如 Asgard，它是 Netflix（ https://github.com/Netflix/asgard ）构建和使用的基于 Web 的云管理和部署工具。纯理论讲得够多了，让我们在机器上安装 Gradle 并构建第一个项目，让自己的脚步变得更快。在第 3 章中，我们将进一步探讨如何使用 Gradle 实现并运行一个复杂的 Java 项目。