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

# 管道执行的工作原理
<a name="concepts-how-it-works"></a>

本节概述了 CodePipeline 处理一组变更的方式。 CodePipeline跟踪手动启动管道或更改源代码时开始的每次管道执行。 CodePipeline 使用以下执行模式来处理每次执行在管道中的进展方式。有关更多信息，请参阅 [设置或更改管道执行模式](execution-modes.md)。
+ SUPERSEDED 模式：新的执行可以超越旧的执行。这是默认值。
+ QUEUED 模式：执行按队列顺序逐一处理。这需要管道类型 V2。
+ PARALLEL 模式：在 PARALLEL 模式下，执行同时运行，彼此独立。执行不会等待其它运行完成后才开始或结束。这需要管道类型 V2。
**重要**  
对于处于 PARALLEL 模式的管道，阶段回滚不可用。同样，具有回滚结果类型的故障条件无法添加到 PARALLEL 模式管道中。

## 管道执行的启动方式
<a name="concepts-how-it-works-starting"></a>

您可以在更改源代码或手动启动管道时开始执行。您也可以通过您安排的 Amazon Ev CloudWatch ents 规则触发执行。例如，将源代码更改推送到配置为管道源操作的存储库时，管道检测到更改并开始执行。

**注意**  
如果管道包含多个源操作，将再次运行所有这些操作，即使仅在一个源操作中检测到更改也是如此。

## 管道执行中如何处理源修订
<a name="concepts-how-revisions-processed"></a>

对于每次以源代码更改（源修订）开始的管道执行，源修订的确定方法如下。
+ 对于有 CodeCommit 源的管道，HEAD CodePipeline 将在推送提交的那一刻被克隆。例如，推送一次提交，就会启动执行 1 的管道。当第二次推送提交时，就会启动执行 2 的管道。
**注意**  
对于处于并行模式且带有 CodeCommit 源的管道，无论触发管道执行的提交如何，源操作都将在启动时克隆 HEAD。有关更多信息，请参阅 [CodeCommit 或者并行模式下的 S3 源版本可能与 EventBridge 事件不匹配](troubleshooting.md#troubleshooting-revisions-parallel)。
+ 对于具有 S3 源的管道，将使用 S3 存储桶更新 EventBridge 事件。例如，当源存储桶中的文件更新时，就会生成事件，从而启动执行 1 的管道。当发生第二个存储桶更新的事件时，就会启动执行 2 的管道。
**注意**  
对于使用 S3 源的 PARALLEL 模式管道，无论触发执行的图像标签是什么，源操作总是从最新的图像标签开始。有关更多信息，请参阅 [CodeCommit 或者并行模式下的 S3 源版本可能与 EventBridge 事件不匹配](troubleshooting.md#troubleshooting-revisions-parallel)。
+ 对于具有连接源的管道，例如连接到 Bitbucket 的管道，HEAD 将在推送提交的那一 CodePipeline 刻被克隆。例如，对于 PARALLEL 模式下的管道，推送一次提交，启动管道执行 1，管道执行 2 使用第二次提交。

## 源置换如何与 EventBridge 输入变压器配合使用
<a name="concepts-how-source-overrides-work"></a>

您可以使用覆盖来启动一个管道，该管道具有您为管道执行提供的特定源修订 ID。例如，如果您想启动一个管道来处理来自您的 CodeCommit 来源的特定提交 ID，则可以在启动管道时将提交 ID 添加为替代。

`revisionType` 有四种类型的源修订：
+ `COMMIT_ID`
+ `IMAGE_DIGEST`
+ `S3_OBJECT_VERSION_ID`
+ `S3_OBJECT_KEY`

**注意**  
对于 `COMMIT_ID` 和 `IMAGE_DIGEST` 类型的源修订，源修订 ID 适用于存储库中所有分支的所有内容。

**注意**  
对于`S3_OBJECT_VERSION_ID`和`S3_OBJECT_KEY`类型的源修订版本，两种类型都可以单独使用，也可以将它们一起使用以使用特定的 ObjectKey 和版本标识来覆盖源代码。对于 `S3_OBJECT_KEY`，配置参数 `AllowOverrideForS3ObjectKey` 需要设置为 `true`。有关 S3 源配置参数的更多信息，请参阅 [配置参数](action-reference-S3.md#action-reference-S3-config)。

您可以使用中的 EventBridge输入变压器指定源覆盖。使用输入转换器通过以下一种形式传递数据：
+ 您可以使用输入转换器将数据作为 JSON 参数传递。
+ 您可以使用输入转换器来传递管道变量。

有关将数据作为 JSON 参数传递的示例[Amazon ECR 源操作和 EventBridge 资源](create-cwe-ecr-source.md)，[连接到使用 EventBridge 和的 Amazon S3 源操作 Amazon CloudTrail](create-cloudtrail-S3-source.md)请参阅 S3 和 f [CodeCommit 源操作和 EventBridge](triggering.md) or CodeCommit。

## 管道执行的停止方式
<a name="concepts-how-it-works-stopping"></a>

要使用控制台停止管道执行，您可以在管道可视化页面、执行历史记录页面或详细历史记录页面上选择**停止执行**。要使用 CLI 停止管道执行，请使用 `stop-pipeline-execution` 命令。有关更多信息，请参阅 [在中停止管道执行 CodePipeline](pipelines-stop.md)。

可以使用两种方法停止管道执行：
+ **停止并等待：**允许完成所有进行中的操作执行，并且不会启动后续操作。管道执行不会继续到后续阶段。您不能对已处于 `Stopping` 状态的执行使用此选项。
+ **停止并放弃：**放弃所有进行中的操作执行并且不完成，不会启动后续操作。管道执行不会继续到后续阶段。您可以对已处于 `Stopping` 状态的执行使用此选项。
**注意**  
此选项会导致任务失败或任务次序混乱。

每个选项都会导致管道和操作执行阶段的顺序不同，如下所示。

**选项 1：停止并等待**

当您选择停止并等待时，选定的执行将继续，直到进行中的操作完成。例如，在生成操作正在进行时，以下管道执行会停止。

1. 在管道视图中显示成功消息横幅，并且生成操作会继续，直到完成。管道执行状态为**正在停止**。

   在历史记录视图中，进行中的操作（例如生成操作）的状态为**进行中**，直到生成操作完成。操作正在进行时，管道执行状态为**正在停止**。

1. 停止过程完成后，执行停止。如果已成功完成生成操作，则其状态为**已成功**，并且管道执行显示**已停止**状态。后续操作不会启动。**重试**按钮已启用。

   在历史记录视图中，完成进行中的操作之后，执行状态为**已停止**。  
![\[该图显示历史记录视图，其中执行中的操作完成后，执行状态为 Stopped\]](http://docs.amazonaws.cn/codepipeline/latest/userguide/images/stop-exec-wait-hist-1.png)

**选项 2：停止并放弃**

当您选择停止并放弃时，选定的执行不会等待进行中的操作完成。放弃这些操作。例如，在生成操作进行期间，停止并放弃以下管道执行。

1. 在管道视图中显示成功消息横幅，生成操作显示**进行中**状态，管道执行显示**正在停止**状态。

1. 管道执行停止后，生成操作显示**已放弃**状态，管道执行显示**已停止**状态。后续操作不会启动。**重试**按钮已启用。

1. 在历史记录视图中，执行状态为**已停止**。  
![\[该图显示历史记录视图，其中执行状态为 Stopped\]](http://docs.amazonaws.cn/codepipeline/latest/userguide/images/stop-exec-abandon-hist-1.png)

**停止管道执行的使用案例**

我们建议您使用停止并等待选项来停止管道执行。此选项更安全，因为它可以避免管道中可能出现的失败或 out-of-sequence任务。在中放弃操作后 CodePipeline，操作提供者会继续执行与该操作相关的所有任务。对于 Amazon CloudFormation 操作，管道中的部署操作将被放弃，但堆栈更新可能会继续进行并导致更新失败。

举个可能导致 out-of-sequence任务的放弃操作的示例，如果您通过 S3 部署操作部署一个大文件 (1GB)，并且在部署已经进行时选择停止并放弃该操作，则该操作将在中放弃 CodePipeline，但会在 Amazon S3 中继续执行。Amazon S3 没有收到任何取消上传的指令。接下来，如果您使用非常小的文件启动新的管道执行，则现在有两个部署正在进行。由于新执行的文件很小，因此新部署会在旧部署仍在上传的情况下完成。当旧部署完成后，旧文件会覆盖新文件。

如果有自定义操作，不妨使用停止并放弃选项。例如，如果您有一个自定义操作，其中包含的工作不需要在开始新执行以修复错误之前完成，则可以放弃该操作。

## 在 SUPERSEDED 模式下如何处理执行
<a name="concepts-how-it-works-executions"></a>

处理执行的默认模式是 SUPERSEDED 模式。执行包含一组由执行选取并处理的更改。管道可以同时处理多个执行。每个执行都单独在管道中运行。管道按顺序处理每个执行，并且可能使用较后的执行取代较早的执行。以下规则用于在 SUPERSEDED 模式下处理管道中的执行。

**规则 1：处理执行时锁定阶段**

由于每个阶段一次只能处理一个执行，因此阶段在处理过程中锁定。当执行完成某个阶段时，它会过渡到管道中的下一个阶段。

![\[该图显示正在进行的阶段被锁定\]](http://docs.amazonaws.cn/codepipeline/latest/userguide/images/Promotion.png)


**规则 2：后续执行等待阶段取消锁定**

当某个阶段处于锁定状态时，等待中的执行将停留在锁定阶段之前。在阶段被视为完成之前，为该阶段配置的所有操作必须都已成功完成。执行失败将释放阶段锁定。当执行停止时，执行不会在阶段中继续，并且该阶段会解锁。

**注意**  
在停止执行之前，我们建议您禁用阶段前的转换。这样，当阶段由于停止执行而解锁时，阶段不接受后续的管道执行。

![\[该图显示当第 2 阶段被锁定时，等待中的执行如何在各阶段之间等待\]](http://docs.amazonaws.cn/codepipeline/latest/userguide/images/Waiting.png)


**规则 3：更新的执行将取代等待中的执行**

只会取代处于阶段之间的执行。一个锁定的阶段在该阶段之前挂起一个执行，等待该阶段完成。更新的执行会取代等待中的执行，并在阶段解锁后立即继续进入下一阶段。被取代的执行不会继续。在此示例中，执行 2 在等待锁定阶段时被执行 3 取代。执行 3 下一步进入阶段。

![\[该图显示等待中的执行如何被执行 3 取代\]](http://docs.amazonaws.cn/codepipeline/latest/userguide/images/Batching.png)


有关查看和切换执行模式的注意事项，请参阅[设置或更改管道执行模式](execution-modes.md)。有关执行模式配额的更多信息，请参阅[Amazon CodePipeline 中的限额](limits.md)。

## 在 QUEUED 模式下如何处理执行
<a name="concepts-how-it-works-executions-queued"></a>

对于 QUEUED 模式下的管道，当正在处理一个执行时，阶段会被锁定；但是，等待中的执行不会超越已经开始的执行。

等待中的执行按到达阶段的先后顺序聚集在锁定阶段的入口处，形成等待中的执行队列。在 QUEUED 模式下，可以在同一管道中设置多个队列。当排队的执行进入某个阶段时，该阶段将被锁定，其它执行无法进入。此行为与 SUPERSEDED 模式相同。执行完成该阶段后，该阶段将解锁，并为下一次执行做好准备。

下图显示了 QUEUED 模式管道中的各阶段如何处理执行。例如，当源阶段处理执行 5 时，6 和 7 的执行会形成队列 \$11，并在阶段入口处等待。阶段解锁后，将处理队列中的下一个执行。

![\[显示设置为 QUEUED 模式的管道中执行的示意图。\]](http://docs.amazonaws.cn/codepipeline/latest/userguide/images/Queued-Execution-Mode.png)


有关查看和切换执行模式的注意事项，请参阅[设置或更改管道执行模式](execution-modes.md)。有关执行模式配额的更多信息，请参阅[Amazon CodePipeline 中的限额](limits.md)。

## 在 PARALLEL 模式下如何处理执行
<a name="concepts-how-it-works-executions-parallel"></a>

对于 PARALLEL 模式下的管道，执行是相互独立的，不会等待其它执行完成后才开始。没有队列。要查看管道中的并行执行，请使用执行历史记录视图。

在开发环境中使用 PARALLEL 模式，每个功能都有自己的功能分支，并部署到不与其他用户共享的目标。

有关查看和切换执行模式的注意事项，请参阅[设置或更改管道执行模式](execution-modes.md)。有关执行模式配额的更多信息，请参阅[Amazon CodePipeline 中的限额](limits.md)。

## 管理管道流
<a name="concepts-how-it-works-transitions-approvals"></a>



管道执行流程可以由以下环节控制：
+ 一个*过渡*，用于控制执行进入阶段的流程。可以启用或禁用过渡。禁用过渡后，管道执行将无法进入阶段。等待进入禁用了过渡的阶段的管道执行称为入站执行。启用过渡之后，入站执行将进入阶段并将其锁定。

  与等待锁定阶段的执行类似，在禁用过渡时，等待进入阶段的执行仍可被新执行取代。重新启用已禁用过渡时，最新的执行以及在禁用过渡时已被取代的较早执行将进入阶段。
+ *审批操作* 可防止在授予权限之前管道过渡到下一个操作（例如，授权身份的手动批准）。例如，如果您希望控制管道过渡到最终**生产阶段**的时间，则可以使用审批操作。
**注意**  
具有审批操作的阶段被锁定，直到审批操作获得批准、被拒绝或者超时。超时审批操作的处理方式与失败操作相同。
+ 当阶段中的操作未成功完成时即*失败*。修订不会过渡到该阶段的下一个操作或管道中的下一阶段。可能会发生以下情况：
  + 您手动重试包含失败操作的阶段。这将恢复执行（它重试失败的操作，如果操作成功，将在阶段/管道中继续）。
  + 另一个执行进入失败阶段并取代失败的执行。此时，无法重试失败的执行。

### 推荐的管道结构
<a name="concepts-recommended-pipeline-method"></a>

在决定代码更改应如何通过您的管道流程时，最好对一个阶段中的相关操作分组，以便在阶段锁定时，操作均会处理相同的执行。您可以为每个应用程序环境或可用区等创建一个阶段。 Amazon Web Services 区域具有太多阶段（也就是说太细致）的管道可能会允许过多的并发更改，而在一个较大阶段中具有许多操作（太粗糙）的管道可能需要太长时间才能发布更改。

例如，在同一阶段执行部署操作后的测试操作可以确保测试已部署的相同更改。在此示例中，更改部署到测试环境并进行测试，然后将来自测试环境的最新更改部署到生产环境。在推荐的示例中，测试环境和生产环境是独立的阶段。

![\[该图显示两种类型的阶段操作分组，推荐的选项在左边\]](http://docs.amazonaws.cn/codepipeline/latest/userguide/images/structure-example-recommended-notrecommended.png)


### 入站执行的工作原理
<a name="how-it-works-inbound-executions"></a>

入站执行是一种在向前移动之前等待不可用的阶段、过渡或操作变为可用状态的执行。下一阶段、过渡或操作可能不可用，原因是：
+ 另一执行已进入下一阶段并将其锁定。
+ 进入下一阶段的过渡已禁用。

如果您想控制当前执行是否有时间在后续阶段完成，或者您想在某个时间点停止所有操作，则可以禁用过渡以保持入站执行。要确定是否有入站执行，可以在控制台中查看管道或查看 **get-pipeline-state** 命令的输出。

入站执行需要考虑以下注意事项：
+ 一旦操作、过渡或锁定阶段可用，正在进行的入站执行就会进入该阶段并继续通过管道。
+ 在入站执行等待时，可以手动将其停止。入站执行可以具有 `InProgress`、`Stopped` 或 `Failed` 状态。
+ 当入站执行已停止或失败时，无法重试，因为没有失败的操作可供重试。当入站执行已停止并启用过渡时，停止的入站执行不会继续到该阶段。

您可以查看或停止入站执行。