1. 简介

CodePipeline 是一种持续交付服务，可自动生成和测试您的软件并将其部署到生产环境中。

定价：
AWS CodePipeline 无需预付费用或使用承诺。您仅需按实际用量付费。

每月每个活动管道* 的 AWS CodePipeline 费用为 1.00 USD。为了鼓励用户体验，管道在创建后前 30 天免费。

  • 活动管道是指已存在超过 30 天，并且在一个月内至少发生过一次代码更改的管道。在一个月内未发生过新代码更改的管道不收取费用。使用时间不足一个月的活动管道仍按一个月收取费用。

AWS CodePipeline 包含在 AWS 免费套餐内，每月为新老客户提供一个免费的活动管道。

2. DevOps 管道示例

AWS CodePipeline - 图1
例如，开发人员将修复推送到 Web 应用程序，并将发生以下情况：

  1. 应用程序源代码的配置为 GitHub 源操作。当开发人员将提交推送到存储库时，CodePipeline 检测推送的更改，管道执行从源阶段开始。
  2. GitHub 的源操作已成功完成 (即，最新更改已下载并存储到该执行所特有的工件桶中)。
  3. 管道执行从源阶段转换到生产阶段。生产阶段中的第一个操作运行在 CodeBuild 中创建的构件项目，并在管道中配置作为构建操作。构建任务提取构建环境映像，然后在虚拟容器中构建 Web 应用程序。
  4. 生产阶段中的下一个操作是在 CodeBuild 中创建的单元测试项目，并在管道中配置测试操作。
  5. 单元测试的代码接下来由生产阶段中的部署操作处理，该操作将应用程序部署到生产环境。部署操作成功完成后，阶段中的最终操作是在 CodeBuild 中创建的集成测试项目，并在管道中配置为测试操作。测试操作调用在 Web 应用程序上安装和运行测试工具（如链接检查器）的 shell 脚本。成功完成后，输出是一个构建 Web 应用程序和一组测试结果。

开发人员可以向管道添加操作，以便在构建并针对每个更改测试应用程序后，对其进行部署或进一步测试。

3. 管道执行的工作原理

3.1 管道执行的启动方式

您可以在更改源代码时触发执行，或者手动启动管道。

您还可以通过计划的 Amazon CloudWatch Events 规则触发执行。例如，将源代码更改推送到配置为管道源操作的存储库时，管道检测到更改并开始执行。

3.2 管道执行的停止方式

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

  • 停止并等待: 允许完成所有进行中的操作执行,并且不会启动后续操作。管道执行不会继续到后续阶段。您不能对已处于 Stopping 状态的执行使用此选项。
  • 停止和放弃: 所有进行中的操作执行将被放弃，并且无法完成，并且后续操作不会启动。管道执行不会继续到后续阶段。您可以对已处于 Stopping 状态的执行使用此选项。

停止管道执行的使用案例
我们建议您使用停止并等待选项来停止管道执行。此选项更安全，因为它可避免在管道中出现失败或次序混乱的任务。

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

3.3 在管道中处理执行的方式

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

规则1: 处理执行时,环节被锁定
由于每个阶段一次只能处理一个执行，因此阶段在处理过程中锁定。当执行完成某个阶段时，它会过渡到管道中的下一个阶段。
AWS CodePipeline - 图2
之前: Stage 1 is locked as Execution 1 enters. 之后: Stage 2 is locked as Execution 1 enters.

规则2: 后续执行等待环节解锁
当某个阶段处于锁定状态时，等待中的执行将停留在锁定阶段之前。在阶段被视为完成之前，为该阶段配置的所有操作必须都已成功完成。执行失败将释放阶段锁定。当执行停止时，执行不会在阶段中继续，并且该阶段会解锁。AWS CodePipeline - 图3
之前: Stage 2 is locked as Execution 1 enters. 之后: Execution 2 exits Stage 1 and waits between stages.

规则3: 等待的执行将被最近的执行取代
只会取代处于阶段之间的执行。一个锁定的阶段在该阶段之前挂起一个执行，等待该阶段完成。更新的执行会取代等待中的执行，并在阶段解锁后立即继续进入下一阶段。被取代的执行不会继续。在此示例中，执行 2 在等待锁定阶段时被执行 3 取代。执行 3 下一步进入阶段。
AWS CodePipeline - 图4
之前：在执行 3 进入阶段 1 时，执行 2 在阶段之间等待。之后：执行 3 退出阶段 1。执行 2 被执行 3 取代。

4. 推荐的管道结构

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

例如，在同一阶段执行部署操作后的测试操作可以确保测试已部署的相同更改。在此示例中，更改部署到测试环境并进行测试，然后将来自测试环境的最新更改部署到生产环境。在推荐的示例中，测试环境和生产环境是独立的阶段。
AWS CodePipeline - 图5
左：相关测试、部署和批准操作分组在一起（推荐）。右：相关操作位于独立的阶段中（不推荐）。

5. 开始使用 CodePipeline

  1. 阅读CodePipeline 概念部分，了解 CodePipeline 如何工作。
  2. 按照CodePipeline 入门中的步骤操作，准备使用 CodePipeline。
  3. 按照CodePipeline 教程教程中的步骤操作，试用 CodePipeline。
  4. 按照在 CodePipeline 中创建管道中的步骤操作，对您的新项目或现有项目使用 CodePipeline。