请翻译：Our end goal is to automate the full process from code commit to production Before looking into the production stage of the deployment pipeline let’s verify that the customizations we’ve defined s

我们的最终目标是自动化从代码提交到生产的整个流程。在研究部署流水线的生产阶段之前，让我们通过手动在生产环境中部署目录服务来验证我们到目前为止定义的自定义内容是否正确。

正如您在上一章中学到的，我们可以使用Kubernetes CLI从Kustomization叠加上部署应用程序到Kubernetes。打开一个终端窗口，导航到目录服务的生产叠加文件夹（polar-deployment/kubernetes/applications/catalog-service/production），并运行以下命令通过Kustomize部署应用程序：

您可以通过运行此命令来跟踪它们的进度，并查看两个应用程序实例何时准备好接收请求：

要获取有关部署的其他信息，您可以继续使用Kubernetes CLI或依赖于Octant，这是一个通过方便的图形界面可视化Kubernetes工作负载的工具。如第7章所述，您可以使用命令octant启动Octant。此外，应用程序日志可能对验证目录服务是否正常运行很有帮助：

该应用程序目前尚未在集群外部公开（需要Edge Service），但您可以使用端口转发功能将流量从本地环境的9001端口转发到集群中运行的服务的80端口：

由kubectl port-forward命令启动的进程将持续运行，直到您使用Ctrl-C显式停止它。

现在，您可以在本地机器上的9001端口调用目录服务，请求将被转发到Kubernetes集群中的Service对象。打开一个新的终端窗口，并调用应用程序公开的根端点，以验证生产Spring配置文件的ConfigMap中指定的polar.greeting值是否被使用，而不是默认值：

恭喜！您正式进入生产环境！完成后，您可以使用Ctrl-C终止端口转发。最后，通过在目录服务的生产叠加文件夹中运行以下命令来删除部署：

Kubernetes提供了实施不同类型部署策略的基础设施。当我们将应用程序清单更新为新的发布版本并将其应用于集群时，Kubernetes执行滚动更新。这种策略通过逐步更新Pod实例来保证用户的零停机时间。您在上一章中看到了它的运作方式。

默认情况下，Kubernetes采用滚动更新策略，但也有其他技术可以基于标准Kubernetes资源使用，或者可以依赖于像Knative这样的工具。例如，您可能希望使用蓝/绿部署，即在第二个生产环境中部署软件的新版本。通过这样做，您可以最后一次测试一切是否运行正常。当环境准备好后，将流量从第一个（蓝色）切换到第二个（绿色）生产环境。[1]

另一种部署技术是金丝雀发布。它与蓝/绿部署类似，但从蓝色环境向绿色环境的流量逐渐移动。其目标是首先向一小部分用户推出更改，进行一些验证，然后逐渐向越来越多的用户进行相同的操作，直到所有人都使用新版本。[2]蓝/绿部署和金丝雀发布都提供了一种简单的方式来回滚更改。

如果您对在Kubernetes上进行部署和发布策略更感兴趣，我推荐阅读Mauricio Salatino的《Continuous Delivery for Kubernetes》中的第5章，该书由Manning出版（https://livebook.manning.com/book/continuous-delivery-for-kubernetes/chapter-5）。

目前，每次您提交更改时，一个新的发布候选版本最终会被发布并在通过提交和验收阶段的成功后获得批准。然后，您需要复制新的发布候选版本的版本号，并将其粘贴到Kubernetes清单中，然后才能手动更新应用程序在生产环境中。在下一节中，您将看到如何通过实施部署流水线的最后一部分（生产阶段）自动化该过程