本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
管道执行的工作原理
本节概述了 CodePipeline 处理一组变更的方式。 CodePipeline跟踪手动启动管道或更改源代码时开始的每次管道执行。 CodePipeline使用以下执行模式来处理每次执行在管道中的进展方式。
-
被取代模式：较新的执行可能会超过较旧的执行。这是默认模式。
-
队列模式：执行按排队的顺序逐一处理。这需要管道类型 V2。
-
并行模式：在并行模式下，执行是同时独立运行的。执行不会等到其他运行完成后才开始或完成。这需要管道类型 V2。
管道执行的启动方式
您可以在更改源代码或手动启动管道时开始执行。您也可以通过您安排的 Amazon Ev CloudWatch ents 规则触发执行。例如，将源代码更改推送到配置为管道源操作的存储库时，管道检测到更改并开始执行。
注意
如果管道包含多个源操作，将再次运行所有这些操作，即使仅在一个源操作中检测到更改也是如此。
管道执行的停止方式
要使用控制台停止管道执行，您可以在管道可视化页面、执行历史记录页面或详细历史记录页面上选择停止执行。要使用 CLI 停止管道执行，请使用 stop-pipeline-execution 命令。有关更多信息，请参阅在 CodePipeline 中停止管道执行。
可以使用两种方法停止管道执行：
-
停止并等待：允许完成所有进行中的操作执行，并且不会启动后续操作。管道执行不会继续到后续阶段。您不能对已处于
Stopping状态的执行使用此选项。 -
停止并放弃：放弃所有进行中的操作执行并且不完成，不会启动后续操作。管道执行不会继续到后续阶段。您可以对已处于
Stopping状态的执行使用此选项。注意
此选项会导致任务失败或任务次序混乱。
每个选项都会导致管道和操作执行阶段的顺序不同，如下所示。
选项 1：停止并等待
当您选择停止并等待时，选定的执行将继续，直到进行中的操作完成。例如，在生成操作正在进行时，以下管道执行会停止。
-
在管道视图中显示成功消息横幅，并且生成操作会继续，直到完成。管道执行状态为正在停止。
在历史记录视图中，进行中的操作（例如生成操作）的状态为进行中，直到生成操作完成。操作正在进行时，管道执行状态为正在停止。
-
停止过程完成后，执行停止。如果已成功完成生成操作，则其状态为已成功，并且管道执行显示已停止状态。后续操作不会启动。重试按钮已启用。
在历史记录视图中，完成进行中的操作之后，执行状态为已停止。
选项 2：停止并放弃
当您选择停止并放弃时，选定的执行不会等待进行中的操作完成。放弃这些操作。例如，在生成操作进行期间，停止并放弃以下管道执行。
-
在管道视图中显示成功消息横幅，生成操作显示进行中状态，管道执行显示正在停止状态。
-
管道执行停止后，生成操作显示已放弃状态，管道执行显示已停止状态。后续操作不会启动。重试按钮已启用。
-
在历史记录视图中，执行状态为已停止。
停止管道执行的使用案例
我们建议您使用停止并等待选项来停止管道执行。此选项更安全，因为它可以避免管道中可能出现的失败或 out-of-sequence 任务。在中放弃操作后 CodePipeline，操作提供者会继续执行与该操作相关的所有任务。如果是 AWS CloudFormation 操作，则会放弃管道中的部署操作，但堆栈更新可能会继续并导致更新失败。
举个可能导致 out-of-sequence 任务的放弃操作的示例，如果您通过 S3 部署操作部署一个大文件 (1GB)，并且在部署已经进行时选择停止并放弃该操作，则该操作将在中放弃 CodePipeline，但会在 Amazon S3 中继续执行。Amazon S3 没有收到任何取消上传的指令。接下来，如果您使用非常小的文件启动新的管道执行，则现在有两个部署正在进行。由于新执行的文件很小，因此新部署会在旧部署仍在上传的情况下完成。当旧部署完成后，旧文件会覆盖新文件。
如果有自定义操作，不妨使用停止并放弃选项。例如，如果您有一个自定义操作，其中包含的工作不需要在开始新执行以修复错误之前完成，则可以放弃该操作。
如何在 SUPERSEDED 模式下处理执行
处理执行的默认模式是取代模式。执行包含一组由执行选取并处理的更改。管道可以同时处理多个执行。每个执行都单独在管道中运行。管道按顺序处理每个执行，并且可能使用较后的执行取代较早的执行。以下规则用于在 SUPERSEDED 模式下处理管道中的执行。
规则 1：处理执行时锁定阶段
由于每个阶段一次只能处理一个执行，因此阶段在处理过程中锁定。当执行完成某个阶段时，它会过渡到管道中的下一个阶段。
规则 2：后续执行等待阶段取消锁定
当某个阶段处于锁定状态时，等待中的执行将停留在锁定阶段之前。在阶段被视为完成之前，为该阶段配置的所有操作必须都已成功完成。执行失败将释放阶段锁定。当执行停止时，执行不会在阶段中继续，并且该阶段会解锁。
注意
在停止执行之前，我们建议您禁用阶段前的转换。这样，当阶段由于停止执行而解锁时，阶段不接受后续的管道执行。
规则 3：更新的执行将取代等待中的执行
只会取代处于阶段之间的执行。一个锁定的阶段在该阶段之前挂起一个执行，等待该阶段完成。更新的执行会取代等待中的执行，并在阶段解锁后立即继续进入下一阶段。被取代的执行不会继续。在此示例中，执行 2 在等待锁定阶段时被执行 3 取代。执行 3 下一步进入阶段。
之前：在执行 3 进入阶段 1 时，执行 2 在阶段之间等待。之后：执行 3 退出阶段 1。执行 2 被执行 3 取代。
如何在排队模式下处理执行
对于处于 QUEUED 模式的管道，处理执行时阶段会被锁定；但是，等待的执行不会超过已经开始的执行。
等待的执行按到达阶段的顺序聚集在锁定阶段的入口点，形成等待的执行队列。在 QUEUED 模式下，您可以在同一个管道中拥有多个队列。当排队的执行进入某个阶段时，该阶段将被锁定，其他执行都无法进入。此行为与 SUPERSEDED 模式相同。执行完成该阶段后，该阶段将处于解锁状态，为下一次执行做好准备。
下图显示了排队模式管道中的各个阶段是如何处理执行的。例如，当源阶段处理执行 5 时，6 和 7 的执行形成队列 #1 并在阶段入口点等待。队列中的下一次执行将在阶段解锁后处理。
有关使用执行模式的配额的更多信息，请参阅AWS CodePipeline 中的配额。
如何在并行模式下处理执行
对于处于并行模式的管道，执行相互独立，无需等待其他执行完成后再开始。没有队列。要查看管道中的并行执行，请使用执行历史视图。
在开发环境中使用并行模式，在这种环境中，每个功能都有自己的功能分支，并部署到其他用户未共享的目标。
有关使用执行模式的配额的更多信息，请参阅AWS CodePipeline 中的配额。
管理管道流
管道执行流程可以由以下环节控制：
-
一个过渡，用于控制执行进入阶段的流程。可以启用或禁用过渡。禁用过渡后，管道执行将无法进入阶段。等待进入禁用了过渡的阶段的管道执行称为入站执行。启用过渡之后，入站执行将进入阶段并将其锁定。
与等待锁定阶段的执行类似，在禁用过渡时，等待进入阶段的执行仍可被新执行取代。重新启用已禁用过渡时，最新的执行以及在禁用过渡时已被取代的较早执行将进入阶段。
-
审批操作 可防止在授予权限之前管道过渡到下一个操作（例如，授权身份的手动批准）。例如，如果您希望控制管道过渡到最终生产阶段的时间，则可以使用审批操作。
注意
具有审批操作的阶段被锁定，直到审批操作获得批准、被拒绝或者超时。超时审批操作的处理方式与失败操作相同。
-
当阶段中的操作未成功完成时即失败。修订不会过渡到该阶段的下一个操作或管道中的下一阶段。可能会发生以下情况：
-
您手动重试包含失败操作的阶段。这将恢复执行（它重试失败的操作，如果操作成功，将在阶段/管道中继续）。
-
另一个执行进入失败阶段并取代失败的执行。此时，无法重试失败的执行。
-
推荐的管道结构
在决定代码更改应如何通过您的管道流程时，最好对一个阶段中的相关操作分组，以便在阶段锁定时，操作均会处理相同的执行。您可以为每个应用程序环境、AWS 区域或可用区等创建一个阶段。具有太多阶段（也就是说太细致）的管道可能会允许过多的并发更改，而在一个较大阶段中具有许多操作（太粗糙）的管道可能需要太长时间才能发布更改。
例如，在同一阶段执行部署操作后的测试操作可以确保测试已部署的相同更改。在此示例中，更改部署到测试环境并进行测试，然后将来自测试环境的最新更改部署到生产环境。在推荐的示例中，测试环境和生产环境是独立的阶段。
左：相关测试、部署和批准操作分组在一起（推荐）。右：相关操作位于独立的阶段中（不推荐）。
入站执行的工作原理
入站执行是一种在向前移动之前等待不可用的阶段、过渡或操作变为可用状态的执行。下一阶段、过渡或操作可能不可用，原因是：
-
另一执行已进入下一阶段并将其锁定。
-
进入下一阶段的过渡已禁用。
如果您想控制当前执行是否有时间在后续阶段完成，或者您想在某个时间点停止所有操作，则可以禁用过渡以保持入站执行。要确定是否有入站执行，可以在控制台中查看管道或查看 get-pipeline-state 命令的输出。
入站执行需要考虑以下注意事项：
-
一旦操作、过渡或锁定阶段可用，正在进行的入站执行就会进入该阶段并继续通过管道。
-
在入站执行等待时，可以手动将其停止。入站执行可以具有
InProgress、Stopped或Failed状态。 -
当入站执行已停止或失败时，无法重试，因为没有失败的操作可供重试。当入站执行已停止并启用过渡时，停止的入站执行不会继续到该阶段。
您可以查看或停止入站执行。
