请翻译：We started implementing a deployment pipeline back in chapter 3 and we have come a long way since then We’ve automated all the steps from code commit up to having a release candidate ready for pro

我们在第3章开始实施部署流水线，并且我们已经走了很长的路。我们已经自动化了从代码提交到准备好生产的发布候选版本的所有步骤。到目前为止，我们仍然有两个操作是手动执行的：使用新的应用程序版本更新生产脚本，并将其部署到Kubernetes中。

在本节中，我们将开始研究部署流水线的最后一部分，即生产阶段，并向您展示如何将其作为GitHub Actions中的工作流实现。

在发布候选版本经过提交和验收阶段后，我们足够有信心将其部署到生产环境中。生产阶段可以手动或自动触发，具体取决于您是否希望实现持续部署。

持续交付是“一种软件开发纪律，通过这种方式构建软件，使得软件可以随时发布到生产环境。”脚注：[]关键的部分是要理解软件可以发布到生产环境，但不一定要发布。这是持续交付和持续部署之间常见的混淆源。如果您还希望将最新的发布候选版本自动部署到生产环境中，那么您将实现持续部署。

生产阶段包括两个主要步骤：

使用新的发布版本更新部署脚本（在我们的情况下是Kubernetes清单）。

将应用程序部署到生产环境。

注意 一个可选的第三步是运行一些最后的自动化测试，以验证部署是否成功。也许您可以重用在验收阶段中包含的相同系统测试来验证在临时环境中的部署。

下一节将向您展示如何使用GitHub Actions实现生产阶段的第一步，并讨论第二步的一些实现策略。我们将致力于自动化从代码提交到生产的整个路径，并实现持续部署。

与以前的阶段相比，实施部署流水线的生产阶段可能因几个因素而有很大的差异。让我们首先专注于生产阶段的第一步。

在验收阶段结束时，我们有一个经过验证准备好进入生产环境的发布候选版本。之后，我们需要使用新的发布版本更新我们的生产覆盖中的Kubernetes清单。当我们将应用程序源代码和部署脚本保存在同一个存储库中时，生产阶段可以监听由GitHub发布的特定事件，每当验收阶段成功完成时，就像我们在提交和验收阶段之间配置流程一样。

在我们的情况下，我们将部署脚本保存在一个单独的存储库中，这意味着每当验收阶段工作流在应用程序存储库中完成执行时，我们需要通知部署存储库中的生产阶段工作流。GitHub Actions提供了通过自定义事件实现此通知过程的选项。让我们看看它是如何工作的。

打开您的Catalog Service项目（catalog-service），转到.github/workflows文件夹中的acceptance-stage.yml文件。在所有验收测试成功运行后，我们必须定义一个最后的步骤，该步骤将发送一个通知给polar-deployment存储库，并要求其使用新的发布版本更新Catalog Service的生产清单。这将是生产阶段的触发器，我们将在接下来的部分中实现。

通过这个新步骤，如果在执行验收测试期间未发现错误，将向polar-deployment存储库发送通知，以触发Catalog Service的更新。

默认情况下，GitHub Actions不允许您触发其他存储库中的工作流，即使它们都属于您或您的组织。因此，我们需要为repository-dispatch操作提供一个访问令牌，以授予它这样的权限。该令牌可以是个人访问令牌（PAT），这是我们在第6章中使用的GitHub工具。

转到您的GitHub帐户，导航到“设置”>“开发人员设置”>“个人访问令牌”，然后选择“生成新令牌”。输入一个有意义的名称，并为其分配工作流范围，以授予令牌在其他存储库中触发工作流的权限（图15.6）。最后，生成令牌并复制其值。GitHub只会显示一次令牌值。确保保存它，因为您很快就会需要它。

接下来，转到GitHub上的Catalog Service存储库，导航到“设置”选项卡，然后选择“Secrets”>“Actions”。在该页面上，选择“New Repository Secret”，将其命名为DISPATCH_TOKEN（与列表15.17中使用的相同名称），并输入您先前生成的PAT的值。使用GitHub提供的Secrets功能，我们可以安全地将PAT提供给验收阶段工作流。

正如第3章中所解释的，当使用来自GitHub市场的操作时，您应该像处理任何其他第三方应用程序一样处理它们，并相应地管理安全风险。在验收阶段，我们向具有操作存储库和工作流权限的第三方操作提供了访问令牌。您不应该轻率地这样做。在这种情况下，我相信操作的作者，并决定信任操作与令牌。

暂时不要将更改提交到catalog-service存储库。我们稍后再做。此时，我们已经实现了生产阶段的触发器，但还没有初始化最后一个阶段。让我们继续进行Polar Deployment存储库并完成这个过程。

打开您的Polar Deployment项目（polar-deployment），并在一个新的.github/workflows文件夹中创建一个production-stage.yml文件。生产阶段在应用程序存储库的验收阶段调度app_delivery事件时触发。事件本身包含有关最新发布候选版本的应用程序名称、图像和版本的上下文信息。

由于应用程序特定的信息是参数化的，我们可以将此工作流用于Polar Bookshop系统的所有应用程序，而不仅仅是Catalog Service。

生产阶段的第一个作业是使用新的发布版本更新生产Kubernetes清单。该作业将包括三个步骤