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

CodePipeline 概念

如果您了解 AWS CodePipeline 中使用的概念和术语，就可以更容易地建模和配置自动发布流程。以下是使用 CodePipeline 时要了解的一些概念。

有关开发运营管道的示例，请参阅DevOps 管道示例。

CodePipeline 中使用了以下术语：

管线

管道是一种工作流结构，描述软件更改如何经过发布过程。每个管道由一系列阶段 组成。

阶段

阶段用于隔离环境并限制该环境中并发更改数的逻辑单元。每个阶段都包含在应用程序构件上执行的操作。您的源代码是一个构件示例。阶段可能是构建阶段，在该阶段中构建源代码并运行测试。它也可以是部署阶段，在该阶段中将代码部署到运行时环境。每个阶段都由一系列串行或并行操作 组成。

转换

转换 是指管道执行移动到管道中下一阶段的点。您可以禁用某个阶段的入站转换，以防止执行进入该阶段，然后您可以启用转换以允许执行继续。当多个执行达到某个已禁用转换时，在启用转换时，只有最新的执行继续到下一个阶段。这意味着在禁用了转换时，较新的执行将继续取代等待中的执行，然后在启用转换后，继续执行的执行是进行取代的执行。

操作

操作 是对应用程序代码执行的一组操作，并配置为使操作在管道中的指定点运行。这可能包括来自代码更改的源操作、将应用程序部署到实例的操作等。例如，部署阶段可能包含将代码部署到计算服务（例如 Amazon EC2 或 AWS Lambda）的部署操作。

有效的 CodePipeline 操作类型为 source、build、test、deploy、approval 和 invoke。有关操作提供程序的列表，请参阅 中的有效操作提供者 CodePipeline 。

操作能够以串行或并行方式运行。有关阶段中串行和并行操作的信息，请参阅操作结构要求中的 runOrder 信息。

管道执行

执行 是管道发布的一组更改。每个管道执行均唯一并有自己的 ID。一个执行对应于一组更改，例如合并提交或手动发布最新提交。两个执行可以在不同的时间发布相同的一组更改。

虽然管道可以同时处理多个执行，但一个管道阶段一次只处理一个执行。为此，阶段在执行的处理期间将锁定。两个管道执行不能同时占据同一个阶段。等待进入占用阶段的执行称为入站执行。入站执行仍可能失败、被取代或手动停止。有关入站执行如何工作的更多信息，请参阅入站执行的工作原理。

管道执行按顺序遍历管道阶段。管道的有效状态为 InProgress、Stopping、Stopped、Succeeded、Superseded 和 Failed。

有关更多信息，请参阅 PipelineExecution。

停止的执行

可以手动停止管道执行，以便正在进行的管道执行不会继续通过管道。如果手动停止，管道执行会显示 Stopping 状态，直到它完全停止。然后它显示 Stopped 状态。可以重试 Stopped 管道执行。

可以使用两种方法停止管道执行：

有关停止执行的使用案例信息和这些选项的序列详细信息，请参阅管道执行的停止方式。

失败的执行

如果执行失败，则会停止执行并且不会完全遍历管道。其状态为 FAILED 状态，并且阶段取消锁定。更近的执行可以跟上并进入取消锁定的阶段，然后将其锁定。您可以重试失败的执行，除非失败的执行已被取代或不可重试。您可以将失败的阶段回滚到之前成功执行的阶段。

执行模式

要通过管道传递最新的一组更改，将会传递较新的执行，并替换已在管道中运行的较早的执行。发生这种情况时，较新的执行将取代较早的执行。一个执行在特定点（即阶段之间的点）被更新的执行取代。SUPERSEDED 是默认执行模式。

在 SUPERSEDED 模式下，如果某个执行正在等待进入锁定阶段，则更近的执行可能会赶上并取代它。较新的执行现在等待阶段取消锁定，而被取代的执行停止，且状态为 SUPERSEDED。当某个管道执行被取代时，该执行将停止，并且不会完全遍历管道。当某个执行在此阶段中被取代之后，您无法再重试该执行。其它可用的执行模式有 PARALLEL 或 QUEUED 模式。

有关执行模式和锁定阶段的更多信息，请参阅 在 SUPERSEDED 模式下如何处理执行。

阶段操作

当管道执行通过一个阶段时，该阶段处于完成阶段内所有操作的过程中。有关阶段操作的工作方式和锁定阶段的信息，请参阅在 SUPERSEDED 模式下如何处理执行。

有效的阶段状态为 InProgress、Stopping、Stopped、Succeeded 和 Failed。除非失败的阶段不可重试，否则您都可以重试这些阶段。有关更多信息，请参阅 StageExecution。您可以将一个阶段回滚到指定的前一次成功执行。可以配置阶段在失败时自动回滚，详见配置阶段回滚。有关更多信息，请参阅 RollbackStage。

操作执行

操作执行 是完成在指定构件上执行操作的已配置操作的过程。这可以是输入构件和/或输出构件。例如，构建操作可能会在输入构件上运行构建命令，如编译应用程序源代码。操作执行详细信息包括操作执行 ID、相关的管道执行源触发器以及操作的输入和输出构件。

有效的操作状态为 InProgress、Abandoned、Succeeded 和 Failed。有关更多信息，请参阅 ActionExecution。

执行类型

管道或阶段执行可以是标准执行，也可以是回滚执行。

对于标准类型，执行具有唯一 ID，并且是完整管道运行。管道回滚有一个要回滚的阶段，而该阶段的成功执行作为要回滚到的目标执行。目标管道执行用于检索源代码修订和变量，以便阶段重新运行。

操作类型

操作类型 是可在 CodePipeline 中可供选择的预配置的操作。操作类型按照它的所有者、提供方、版本和类别来定义。操作类型可提供自定义参数，用于完成管道中的操作任务。

有关可基于操作类型集成到管道中的 AWS 服务 以及合作伙伴产品和服务的信息，请参阅与 CodePipeline 操作类型的集成。

有关 CodePipeline 中操作类型支持的集成模式的信息，请参阅集成模型参考。

有关第三方提供方如何能够在 CodePipeline 中设置和管理操作类型的信息，请参阅使用操作类型。

构件

构件 是指通过管道操作处理的数据集合，例如应用程序源代码、构建应用程序、依赖关系、定义文件、模板等。构件由一些操作生成，由另外一些操作使用。在管道中，构件可以是操作处理的一组文件（输入构件），或者是已完成操作的更新输出（输出构件）。

通过使用管道构件桶，操作会将输出传递给另一个操作供进一步处理。CodePipeline 会将构件复制到构件存储区，而操作将会这里提取构件。有关构件的更多信息，请参阅 输入和输出构件。

源修订

当您进行源代码更改时，将创建新版本。源修订 是触发管道执行的源更改版本。执行会处理源代码修订。对于 GitHub 和 CodeCommit 存储库，这便是提交。对于 S3 存储桶或操作，则为对象版本。

可以使用您指定的源修订（例如提交）启动管道执行。执行将处理指定的修订，并覆盖本应用于执行的修订。有关更多信息，请参阅 使用源修订覆盖启动管道。

触发

触发器 是会启动管道的事件。一些触发器（如手动启动管道）可供管道中的所有源操作提供程序使用。某些触发器依赖于管道的源提供程序。例如，必须使用来自 Amazon CloudWatch 的事件资源来配置 CloudWatch 事件，这些资源应添加管道 ARN 以作为事件规则中的目标。Amazon CloudWatch Events 是对具有 CodeCommit 或 S3 源操作的管道进行自动更改检测的推荐触发器。Webhook 是一种为第三方存储库事件配置的触发器。例如，WebhookV2 是一种触发器类型，允许使用 Git 标签启动具有第三方源提供方（如 GitHub.com、GitHub Enterprise Server、GitLab.com、GitLab 自行管理或 Bitbucket Cloud）的管道。在管道配置中，您可以指定触发器的筛选条件，如推送请求或拉取请求。您可以根据 Git 标签、分支或文件路径筛选代码推送事件。您可以根据事件（已打开、已更新、已关闭）、分支或文件路径筛选拉取请求事件。

有关触发器的更多信息，请参阅在中启动管道 CodePipeline。有关演示使用 Git 标签作为管道触发器的教程，请参阅教程：使用 Git 标签启动管道。

Variables

变量 是一个值，可用于动态配置管道中的操作。变量可以在管道级别声明，也可以由管道中的操作发出。变量值在管道执行时进行解析，可以在执行历史记录中查看。对于在管道级别声明的变量，可以在管道配置中定义默认值，也可以在给定的执行中覆盖默认值。对于由操作发出的变量，值在操作成功完成后才可用。有关更多信息，请参阅 变量参考。

Conditions

一个条件包含一组需要评估的规则。如果一个条件中的所有规则都成功，则满足该条件。您可以配置条件，以便在不满足标准时，会产生指定的结果，如阶段失败。条件也被称为“门”，因为它们让您能够指定执行何时进入并通过阶段，或在通过阶段后退出阶段。这就好比让道路上的车流在关闭的闸门处聚集，然后指定打开闸门，让车流进入一个区域。条件类型的结果包括阶段失败或阶段回滚。条件有助于您指定这些操作在管道阶段的发生时间。您可以在运行时覆盖条件。

有三种类型的条件。“入口”条件回答的问题是“如果满足条件的规则，则进入阶段”。当执行进入阶段时，阶段被锁定，然后运行规则。对于“失败时”条件，规则会在阶段失败时启用，结果是回滚失败的阶段。对于“成功时”条件，规则会在阶段成功时启用，例如在继续之前检查成功运行是否有警报。例如，如果 CloudWatchAlarm 规则发现部署环境中存在警报，“成功时”条件将导致成功阶段的回滚。有关更多信息，请参阅 阶段条件是如何运作的？。

规则

条件使用一个或多个预配置的规则，这些规则会运行并执行检查，然后在不满足条件时执行配置的结果。例如，满足检查警报状态和部署时段时间的“入口”条件规则的所有规则，将在所有检查通过后部署成功阶段。有关更多信息，请参阅 阶段条件是如何运作的？。