本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# CodePipeline 概念
如果您了解中使用的概念和术语，则可以更轻松地对自动发布流程进行建模和配置 AWS CodePipeline。以下是使用 CodePipeline 时要了解的一些概念。
有关 DevOps 管道的示例，请参见[DevOps 管道示例](concepts-devops-example.md)。
以下术语用于 CodePipeline：
**Topics**
+ [Pipelines](#concepts-pipelines)
+ [管道执行](#concepts-executions)
+ [阶段操作](#concepts-stage-executions)
+ [操作执行](#concepts-action-executions)
+ [执行类型](#concepts-execution-types)
+ [操作类型](#concepts-action-types)
+ [构件](#concepts-artifacts)
+ [源修订](#concepts-source-revisions)
+ [触发器](#concepts-triggers)
+ [变量](#concepts-variables)
+ [Conditions](#concepts-conditions)
+ [Rules](#concepts-rules)
## Pipelines
*管道*是一种工作流结构，描述软件更改如何经过发布过程。每个管道由一系列*阶段* 组成。
### Stages
阶段用于隔离环境并限制该环境中并发更改数的逻辑单元。每个阶段都包含在应用程序[构件](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-artifacts)上执行的操作。您的源代码是一个构件示例。阶段可能是构建阶段，在该阶段中构建源代码并运行测试。它也可以是部署阶段，在该阶段中将代码部署到运行时环境。每个阶段都由一系列串行或并行*操作* 组成。
### 转换
*转换* 是指管道执行移动到管道中下一阶段的点。您可以禁用某个阶段的入站转换，以防止执行进入该阶段，然后您可以启用转换以允许执行继续。当多个执行达到某个已禁用转换时，在启用转换时，只有最新的执行继续到下一个阶段。这意味着在禁用了转换时，较新的执行将继续取代等待中的执行，然后在启用转换后，继续执行的执行是进行取代的执行。
![\[管道包含阶段，而阶段包含由可禁用和启用的过渡分隔的操作。\]](http://docs.aws.amazon.com/zh_cn/codepipeline/latest/userguide/images/pipeline-elements-workflow.png)
### 操作
*操作* 是对应用程序代码执行的一组操作，并配置为使操作在管道中的指定点运行。这可能包括来自代码更改的源操作、将应用程序部署到实例的操作等。例如，部署阶段可能包含部署操作，该操作将代码部署到计算服务（如 Amazon EC2 或 AWS Lambda）。
有效的 CodePipeline 操作类型为`source``build`、`test`、`deploy`、`approval`、和`invoke`。有关操作提供程序的列表，请参阅 [中的有效操作提供者 CodePipeline](actions-valid-providers.md)。
操作能够以串行或并行方式运行。有关阶段中串行和并行操作的信息，请参阅[操作结构要求](https://docs.aws.amazon.com/codepipeline/latest/userguide/reference-pipeline-structure.html#action-requirements)中的 `runOrder` 信息。
## 管道执行
*执行* 是管道发布的一组更改。每个管道执行均唯一并有自己的 ID。一个执行对应于一组更改，例如合并提交或手动发布最新提交。两个执行可以在不同的时间发布相同的一组更改。
虽然管道可以同时处理多个执行，但一个管道阶段一次只处理一个执行。为此，阶段在执行的处理期间将锁定。两个管道执行不能同时占据同一个阶段。等待进入占用阶段的执行称为*入站执行*。入站执行仍可能失败、被取代或手动停止。有关入站执行如何工作的更多信息，请参阅[入站执行的工作原理](concepts-how-it-works.md#how-it-works-inbound-executions)。
管道执行按顺序遍历管道阶段。管道的有效状态为 `InProgress`、`Stopping`、`Stopped`、`Succeeded`、`Superseded` 和 `Failed`。
有关更多信息，请参阅 [PipelineExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineExecution.html)。
### 停止的执行
可以手动停止管道执行，以便正在进行的管道执行不会继续通过管道。如果手动停止，管道执行会显示 `Stopping` 状态，直到它完全停止。然后它显示 `Stopped` 状态。可以重试 `Stopped` 管道执行。
可以使用两种方法停止管道执行：
+ **停止并等待**
+ **停止并放弃**
有关停止执行的使用案例信息和这些选项的序列详细信息，请参阅[管道执行的停止方式](concepts-how-it-works.md#concepts-how-it-works-stopping)。
### 失败的执行
如果执行失败，则会停止执行并且不会完全遍历管道。其状态为 `FAILED` 状态，并且阶段取消锁定。更近的执行可以跟上并进入取消锁定的阶段，然后将其锁定。您可以重试失败的执行，除非失败的执行已被取代或不可重试。您可以将失败的阶段回滚到之前成功执行的阶段。
### 执行模式
要通过管道传递最新的一组更改，将会传递较新的执行，并替换已在管道中运行的较早的执行。发生这种情况时，较新的执行将取代较早的执行。一个执行在特定点（即阶段之间的点）被更新的执行取代。SUPERSEDED 是默认执行模式。
在 SUPERSEDED 模式下，如果某个执行正在等待进入锁定阶段，则更近的执行可能会赶上并取代它。较新的执行现在等待阶段取消锁定，而被取代的执行停止，且状态为 `SUPERSEDED`。当某个管道执行被取代时，该执行将停止，并且不会完全遍历管道。当某个执行在此阶段中被取代之后，您无法再重试该执行。其它可用的执行模式有 PARALLEL 或 QUEUED 模式。
有关执行模式和锁定阶段的更多信息，请参阅 [在 SUPERSEDED 模式下如何处理执行](concepts-how-it-works.md#concepts-how-it-works-executions)。
## 阶段操作
当管道执行通过一个阶段时，该阶段处于完成阶段内所有操作的过程中。有关阶段操作的工作方式和锁定阶段的信息，请参阅[在 SUPERSEDED 模式下如何处理执行](concepts-how-it-works.md#concepts-how-it-works-executions)。
有效的阶段状态为 `InProgress`、`Stopping`、`Stopped`、`Succeeded` 和 `Failed`。除非失败的阶段不可重试，否则您都可以重试这些阶段。有关更多信息，请参阅 [StageExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageExecution.html)。您可以将一个阶段回滚到指定的前一次成功执行。可以配置阶段在失败时自动回滚，详见[配置阶段回滚](stage-rollback.md)。有关更多信息，请参阅 [RollbackStage](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_RollbackStage.html)。
## 操作执行
*操作执行* 是完成在指定[构件](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-artifacts)上执行操作的已配置操作的过程。这可以是输入构件和/或输出构件。例如，构建操作可能会在输入构件上运行构建命令，如编译应用程序源代码。操作执行详细信息包括操作执行 ID、相关的管道执行源触发器以及操作的输入和输出构件。
有效的操作状态为 `InProgress`、`Abandoned`、`Succeeded` 和 `Failed`。有关更多信息，请参阅 [ActionExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_ActionExecution.html)。
## 执行类型
管道或阶段执行可以是标准执行，也可以是回滚执行。
对于标准类型，执行具有唯一 ID，并且是完整管道运行。管道回滚有一个要回滚的阶段，而该阶段的成功执行作为要回滚到的目标执行。目标管道执行用于检索源代码修订和变量，以便阶段重新运行。
## 操作类型
*操作类型*是预先配置的动作，可在中进行选择。 CodePipeline操作类型按照它的所有者、提供方、版本和类别来定义。操作类型可提供自定义参数，用于完成管道中的操作任务。
有关您可以根据操作类型集成到管道中的第三方产品和服务的信息，请参阅[与动 CodePipeline 作类型的集成](integrations-action-type.md)。 AWS 服务
有关中操作类型支持的集成模型的信息 CodePipeline，请参阅[集成模型参考](reference-integrations.md)。
有关第三方提供商如何在中设置和管理操作类型的信息 CodePipeline，请参阅[使用操作类型](action-types.md)。
## 构件
*构件* 是指通过管道操作处理的数据集合，例如应用程序源代码、构建应用程序、依赖关系、定义文件、模板等。构件由一些操作生成，由另外一些操作使用。在管道中，构件可以是操作处理的一组文件（*输入构件*），或者是已完成操作的更新输出（*输出构件*）。
操作将输出传递给另一个操作，以便使用管道工件存储桶进行进一步处理。 CodePipeline 将工件复制到工件存储区，操作将在那里捡起它们。有关构件的更多信息，请参阅[输入和输出构件](welcome-introducing-artifacts.md)。
## 源修订
当您进行源代码更改时，将创建新版本。*源修订* 是触发管道执行的源更改版本。执行会处理源代码修订。对于 GitHub 和 CodeCommit 存储库，这是提交。对于 S3 存储桶或操作，则为对象版本。
可以使用您指定的源修订（例如提交）启动管道执行。执行将处理指定的修订，并覆盖本应用于执行的修订。有关更多信息，请参阅 [使用源修订覆盖启动管道](pipelines-trigger-source-overrides.md)。
## 触发器
*触发器* 是会启动管道的事件。一些触发器（如手动启动管道）可供管道中的所有源操作提供程序使用。某些触发器依赖于管道的源提供程序。例如，必须使用来自 Amazon CloudWatch 的事件资源配置事件 CloudWatch ，这些资源将管道 ARN 添加为事件规则中的目标。Amazon Ev CloudWatch ents 是推荐的触发器，用于自动检测具有 CodeCommit 或 S3 源操作的管道的更改。Webhook 是一种为第三方存储库事件配置的触发器。例如，WebHookv2 是一种触发器类型，它允许使用 Git 标签启动与第三方源提供商（例如 GitHub .com、En GitHub terprise Server、.com、 GitLab 自我管理或 Bitbuc GitLab ket Cloud）的管道。在管道配置中，您可以指定触发器的筛选条件，如推送请求或拉取请求。您可以根据 Git 标签、分支或文件路径筛选代码推送事件。您可以根据事件（已打开、已更新、已关闭）、分支或文件路径筛选拉取请求事件。
有关触发器的更多信息，请参阅[在中启动管道 CodePipeline](pipelines-about-starting.md)。有关演示使用 Git 标签作为管道触发器的教程，请参阅[教程：使用 Git 标签启动管道](tutorials-github-tags.md)。
**重要**
非活动时间超过 30 天的管道将禁用管道轮询功能。有关更多信息，请参阅管道结构参考[pollingDisabledAt](pipeline-requirements.md#metadata.pollingDisabledAt)中的。有关将管道从轮询迁移为基于事件的更改检测的步骤，请参阅[更改检测方法](change-detection-methods.md)。
## 变量
*变量* 是一个值，可用于动态配置管道中的操作。变量可以在管道级别声明，也可以由管道中的操作发出。变量值在管道执行时进行解析，可以在执行历史记录中查看。对于在管道级别声明的变量，可以在管道配置中定义默认值，也可以在给定的执行中覆盖默认值。对于由操作发出的变量，值在操作成功完成后才可用。有关更多信息，请参阅 [变量参考](reference-variables.md)。
## Conditions
一个*条件*包含一组需要评估的规则。如果一个条件中的所有规则都成功，则满足该条件。您可以配置条件，以便在不满足标准时，会产生指定的结果，如阶段失败。条件也被称为“门”，因为它们让您能够指定执行何时进入并通过阶段，或在通过阶段后退出阶段。这就好比让道路上的车流在关闭的闸门处聚集，然后指定打开闸门，让车流进入一个区域。条件类型的结果包括阶段失败或阶段回滚。条件有助于您指定这些操作在管道阶段的发生时间。您可以在运行时覆盖条件。
有三种类型的条件。“入口”条件回答的问题是“如果满足条件的规则，则进入阶段”。当执行进入阶段时，阶段被锁定，然后运行规则。对于“失败时”条件，规则会在阶段失败时启用，结果是回滚失败的阶段。对于“成功时”条件，规则会在阶段成功时启用，例如在继续之前检查成功运行是否有警报。例如，如果 CloudWatchAlarm 规则发现部署环境中有警报，则 On Success 条件将导致回滚成功阶段。有关更多信息，请参阅 [阶段条件是如何运作的？](concepts-how-it-works-conditions.md)。
## Rules
条件使用一个或多个预配置的*规则*，这些规则会运行并执行检查，然后在不满足条件时执行配置的结果。例如，满足检查警报状态和部署时段时间的“入口”条件规则的所有规则，将在所有检查通过后部署成功阶段。有关更多信息，请参阅 [阶段条件是如何运作的？](concepts-how-it-works-conditions.md)。