

亚马逊 CodeCatalyst 不再向新买家开放。现有客户可以继续正常使用该服务。有关更多信息，请参阅 [如何从中迁移 CodeCatalyst](migration.md)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 要求批准工作流运行
<a name="workflows-approval"></a>

您可以将工作流运行配置为需要先获得批准，然后才能继续。为此，您必须在工作流中添加**批准**[阶段门](workflows-gates.md)。*批准门禁*可阻止工作流程继续进行，直到一组用户或一组用户在 CodeCatalyst 控制台中提交一项或多项批准。在提供了所有的批准后，阶段门将“解锁”，允许恢复工作流运行。

在工作流中使用**批准**阶段门，可以让开发、运营和领导团队有机会先对更改进行审查，然后再面向更广泛的受众进行部署。

有关工作流运行的更多信息，请参阅[运行工作流](workflows-working-runs.md)。

**Topics**
+ [如何解锁批准阶段门？](#workflows-approval-conditions)
+ [何时使用“批准”阶段门](#workflows-approval-when)
+ [谁可以提供批准？](#workflows-approval-who)
+ [如何通知用户需要该用户的批准？](#workflows-approval-notify-methods)
+ [我能否使用“批准”阶段门来阻止工作流运行的启动？](#workflows-approval-prevent)
+ [对于排队、取代和并行运行模式，工作流批准如何运行？](#workflows-approval-run-mode)
+ [示例：“批准”阶段门](workflows-approval-example.md)
+ [添加“批准”阶段门](workflows-approval-add.md)
+ [配置批准通知](workflows-approval-notify.md)
+ [批准或拒绝工作流运行](workflows-approval-approve.md)
+ [“批准”阶段门 YAML](approval-ref.md)

## 如何解锁批准阶段门？
<a name="workflows-approval-conditions"></a>

要解锁**批准**阶段门，必须满足以下*所有*条件：
+ **条件 1**：必须提交所需数量的批准。所需的批准数量是可配置的，并且每个用户只允许提交一次批准。
+ **条件 2**：所有批准必须在阶段门超时之前提交。阶段门在激活 14 天后超时。此时间段不可配置。
+ **条件 3**：没有任何人拒绝工作流运行。一个拒绝就会导致工作流运行失败。
+ **条件 4**：（仅在使用取代运行模式时适用。） 该运行不得被以后的运行所取代。有关更多信息，请参阅 [对于排队、取代和并行运行模式，工作流批准如何运行？](#workflows-approval-run-mode)。

如果不满足任何条件，则 CodeCatalyst 停止工作流程并将运行状态设置为 “**失败**”（在**条件 1** 到 **3** 的情况下）或 “**已取代**”（在**条件 4** 的情况下）。

## 何时使用“批准”阶段门
<a name="workflows-approval-when"></a>

通常，在工作流将应用程序和其他资源部署到生产服务器或任何必须验证质量标准的环境中时，您可以在工作流中使用**批准**阶段门。通过在部署到生产环境之前放置阶段门，您向审阅者提供了机会，在新的软件修订版面向公众发布之前对其进行验证。

## 谁可以提供批准？
<a name="workflows-approval-who"></a>

任何用户，只要是您的项目的成员且具有**贡献者**或**项目管理员**角色，就可以提供批准。具有**空间管理员**角色且属于您的项目空间的用户也可以提供批准。

**注意**  
具有**审阅者**角色的用户无法提供批准。

## 如何通知用户需要该用户的批准？
<a name="workflows-approval-notify-methods"></a>

要通知用户需要该用户的批准，您必须：
+  CodeCatalyst 给他们发一条 Slack 通知。有关更多信息，请参阅 [配置批准通知](workflows-approval-notify.md)。
+ 转到 CodeCatalyst 控制台中 “**批准**” 和 “**拒绝**” 按钮所在的页面，然后将该页面的 URL 粘贴到发给批准者的电子邮件或消息应用程序中。有关如何导航到此页面的更多信息，请参阅[批准或拒绝工作流运行](workflows-approval-approve.md)。

## 我能否使用“批准”阶段门来阻止工作流运行的启动？
<a name="workflows-approval-prevent"></a>

可以，有资格要求。有关更多信息，请参阅[我能否使用阶段门来阻止工作流运行的启动？](workflows-gates.md#workflows-gates-prevent)。

## 对于排队、取代和并行运行模式，工作流批准如何运行？
<a name="workflows-approval-run-mode"></a>

在排队、取代或并行运行模式时，**批准**阶段门的工作方式与[操作](workflows-actions.md)类似。我们建议您阅读[关于排队运行模式](workflows-configure-runs.md#workflows-configure-runs-queued)、[关于取代运行模式](workflows-configure-runs.md#workflows-configure-runs-superseded)、[关于并行运行模式](workflows-configure-runs.md#workflows-configure-runs-parallel)部分以熟悉这些运行模式。在对这些模式有基本的了解后，请返回本节，了解当存在**批准**阶段门时，这些运行模式是如何工作的。

存在**批准**阶段门时，将按以下方式处理运行：
+ 如果您使用[排队运行模式](workflows-configure-runs.md#workflows-configure-runs-queued)，则运行将排队在当前正等待阶段门批准的运行之后。当该阶段门解锁（即所有批准都已给出）时，队列中的下一个运行将进入阶段门，等待批准。此过程继续，排队的运行将通过门 one-by-one进行处理。 [Figure 1](#figure-1-workflow-queued-run-mode-ma)说明了这个过程。
+ 如果您使用[取代运行模式](workflows-configure-runs.md#workflows-configure-runs-superseded)，则其行为与排队运行模式相同，不同之处在于较新的运行不会堆积在阶段门的队列中，而是取代（接管）较早的运行。这里没有队列，任何目前在阶段门等待批准的运行都将被取消并被更新的运行所取代。[Figure 2](#figure-2-workflow-superseded-run-mode-ma) 说明了这个过程。
+ 如果您使用[并行运行模式](workflows-configure-runs.md#workflows-configure-runs-parallel)，则运行将并行启动，不会形成队列。由于每个运行的前面都没有其他运行，因此阶段门会立即处理每个运行。[Figure 3](#figure-3-workflow-parallel-run-mode-ma) 说明了这个过程。

**图 1**：“排队运行模式”和**批准**阶段门

![“批准”阶段门如何与“排队运行模式”配合使用](http://docs.aws.amazon.com/zh_cn/codecatalyst/latest/userguide/images/flows/runmode-queued-ma.png)


**图 2**：“取代运行模式”和**批准**阶段门

![“批准”阶段门如何与“取代运行模式”配合使用](http://docs.aws.amazon.com/zh_cn/codecatalyst/latest/userguide/images/flows/runmode-superseded-ma.png)


**图 3**：“并行运行模式”和**批准**阶段门

![“批准”阶段门如何与“并行运行模式”配合使用](http://docs.aws.amazon.com/zh_cn/codecatalyst/latest/userguide/images/flows/runmode-parallel-ma.png)
