请翻译：Chapter after chapter we have gone through patterns principles and best practices for working with cloud native applications and we’ve built a bookshop system using Spring Boot and Kubernetes It’s

章节之后，我们已经通过模式、原则和最佳实践介绍了与云原生应用程序的工作方式，并且使用Spring Boot和Kubernetes构建了一个书店系统。现在是将Polar Bookshop部署到生产环境的时候了。

我希望你将Polar Bookshop系统的项目存储在GitHub上的单独Git仓库中。如果你之前没有按照前几章的步骤进行操作，你可以参考配套书籍的源代码中的Chapter15/15-begin文件夹，并将其作为定义这些仓库的基础。

本章将指导您完成准备应用程序进入生产环境的一些最后阶段。首先，我将讨论发布候选版本的版本控制策略，以及如何设计部署流水线的验收阶段。然后，您将了解如何配置用于生产的Spring Boot应用程序，并在公共云中的Kubernetes集群上部署它们。接下来，我将向您展示如何通过实现生产阶段来完成部署流水线。

最后，您将使用Argo CD根据GitOps原则实现持续部署。

本章示例的源代码可在Chapter15/15-begin和Chapter15/15-end文件夹中找到，包含项目的初始和最终状态（https://github.com/ThomasVitale/cloud-native-spring-in-action）。

持续交付是我们确定的支持实现云原生目标的基本实践之一：速度、弹性、可扩展性和成本优化。它是一种以整体方式快速、可靠和安全地交付高质量软件的方法。持续交付的主要思想是应用程序始终处于可发布状态。采用持续交付的主要模式是部署流水线，从代码提交到可发布的软件。它应该尽可能自动化，并表示唯一的生产路径。

第3章解释了部署流水线可以由三个关键阶段组成：提交阶段、验收阶段和生产阶段。在整本书中，我们已经将提交阶段作为GitHub Actions中的工作流程自动化。开发人员在将新代码提交到主线后，此阶段会经历构建、单元测试、集成测试、静态代码分析和打包等过程。在此阶段结束时，可执行的应用程序构件将被发布到构件库中。这是一个发布候选版本。

本节将介绍如何为持续交付对发布候选版本进行版本控制。然后，您将了解有关验收阶段、其目的和结果的更多信息。最后，我将向您展示如何在GitHub Actions中实现验收阶段的最小工作流程。在此阶段结束时，发布候选版本将准备好部署到生产环境中。

部署流水线的提交阶段的输出是一个发布候选版本。这是一个应用程序的可部署构件。在我们的案例中，它是一个容器镜像。流水线中的所有后续步骤都将通过不同的测试评估该容器镜像的质量。如果没有问题，发布候选版本最终将部署到生产环境并发布给用户。

发布候选版本存储在构件库中。如果是JAR文件，则将存储在Maven构件库中。在我们的案例中，它是一个容器镜像，并将存储在容器镜像仓库中。特别是，我们将使用GitHub容器镜像仓库。

每个发布候选版本必须具有唯一的标识。到目前为止，我们对所有容器镜像版本都使用了隐式的latest标签。此外，我们忽略了Gradle中每个Spring Boot项目默认配置的0.0.1-SNAPSHOT版本。那么我们应该如何对发布候选版本进行版本控制呢？

一种常用的策略是语义化版本控制（https://semver.org）。它由<主版本>.<次版本>.<修订版本>的标识符组成。您还可以在末尾添加一个连字符，后跟一个字符串，表示预发布版本。默认情况下，从Spring Initializr（https://start.spring.io）生成的Spring Boot项目的版本是0.0.1-SNAPSHOT，它表示快照版本。语义化版本控制的一个变体是日历版本控制（https://calver.org），它将语义化版本控制的概念与日期和时间结合起来。

这两种策略广泛用于开源项目和作为产品发布给客户的软件，因为它们提供了关于新版本包含的内容的隐式信息。例如，我们期望新的主版本包含新的功能和与之前的主版本不兼容的API更改。另一方面，我们期望修订版本的范围有限，并保证向后兼容性。

如果您正在为语义化版本控制有意义的软件项目工作，我建议您查看JReleaser，这是一个发布自动化工具。"其目标是简化创建发布并将构件发布到多个包管理器，同时提供可自定义的选项"（https://jreleaser.org）。

语义化版本控制将需要某种手动步骤来根据发布构件的内容分配版本号：它是否包含破坏性更改？它只包含错误修复吗？当我们有一个版本号时，仍然不清楚新的发布构件中包含了什么，因此我们需要使用Git标签并定义Git提交标识符与版本号之间的映射。

对于快照构件来说，情况变得更加具有挑战性。以Spring Boot项目为例。默认情况下，我们从版本0.0.1-SNAPSHOT开始。在准备好切换到0.0.1版本之前，每当我们将新更改推送到主分支时，提交阶段都将被触发，并且将使用编号0.0.1-SNAPSHOT发布一个新的发布候选版本。在版本0.0.1发布之前，所有发布候选版本都具有相同的编号。这种方法无法确保更改的可追溯性。哪些提交包含在发布候选版本0.0.1-SNAPSHOT中？我们无法得知。此外，它受到使用latest时同样不可靠的影响。每次检索构件时，它可能与上次不同。

当涉及持续交付时，使用像语义化版本控制这样的方法来唯一标识发布候选版本并不理想。当我们遵循持续集成的原则时，每天都会构建许多发布候选版本。每个发布候选版本都有可能被推广到生产环境。我们是否需要根据其内容（主版本、次版本、修订版本）为每个新代码提交更新语义化版本？从代码提交到生产的路径应尽可能自动化，尽量消除人工干预。如果我们选择持续部署，甚至将自动进行推广到生产环境。我们该怎么办？

一种解决方案是使用Git提交哈希来对发布候选版本进行版本控制-这将是自动化、可追溯和可靠的，并且您不需要Git标签。您可以直接使用提交哈希（例如，486105e261cb346b87920aaa4ea6dce6eebd6223）或将其作为生成更人性化的数字的基础。例如，您可以在