3.5 部署流水线：构建和测试

持续交付是一种快速、可靠、安全地交付高质量软件的整体方法，我在第 1 章中已经解释过。采用这种方法的主要模式是部署流水线，它从代码提交延伸到可发布的软件。它应该尽可能自动化，并且应该代表通往生产环境的唯一路径。

基于 Jez Humble 和 Dave Farley 在其著作 Continuous Delivery（Addison-Wesley Professional, 2010）中以及 Dave Farley 在其 Continuous Delivery Pipelines（2021）书中描述的概念，我们可以识别出部署流水线中的几个关键阶段：

• 提交阶段（Commit stage） —— 在开发者将新代码提交到主干之后，此阶段经历构建、单元测试、集成测试、静态代码分析和打包。在此阶段结束时，一个可执行的应用制品被发布到制品仓库。它是一个发布候选。例如，它可以是一个发布到 Maven 仓库的 JAR 制品，或一个发布到容器镜像仓库的容器镜像。此阶段支持持续集成实践。它应该很快，最好在五分钟以内，以便为开发者提供关于其更改的快速反馈，并允许他们继续下一个任务。
• 验收阶段（Acceptance stage） —— 将新的发布候选发布到制品仓库会触发此阶段，该阶段包括将应用部署到类生产环境并运行额外测试以增加对其可发布性的信心。验收阶段中运行的测试通常较慢，但我们应该努力将整个部署流水线执行时间控制在一小时以内。此阶段包含的测试示例有功能验收测试和非功能验收测试，如性能测试、安全测试和合规测试。如有必要，此阶段还可以包括探索性和可用性测试等手动任务。在此阶段结束时，发布候选已准备好随时部署到生产环境。如果我们对其仍不够自信，说明此阶段缺少一些测试。
• 生产阶段（Production stage） —— 在发布候选经历了提交和验收阶段后，我们有足够的信心将其部署到生产环境。此阶段由手动或自动触发，取决于组织是否决定采用持续部署实践。新的发布候选使用与验收阶段中相同（并经过测试）的部署脚本部署到生产环境。可选地，可以运行一些最终的自动化测试来验证部署是否成功。

本节将引导您完成为 Catalog Service 引导部署流水线并定义提交阶段的前几步。然后我将向您展示如何使用 GitHub Actions 自动化这些步骤。