# 实施持续集成和持续交付
本节讨论可以着手在组织中实施 CI/CD 模型的方法。本白皮书不讨论拥有成熟 DevOps 和云转型模式的组织如何构建和使用 CI/CD 管道。为了帮助您踏上 DevOps 之旅，AWS 拥有许多[经认证的 DevOps 合作伙伴](https://aws.amazon.com/devops/partner-solutions/)，它们可提供资源和工具。有关准备迁移到 AWS 云的更多信息，请参阅[构建云运营模型](https://d1.awsstatic.com/whitepapers/building-a-cloud-operating-model.pdf)。
# 持续集成/持续交付的途径
可以将 CI/CD 描绘成一个管道（请参阅下图），其中新代码在一端提交，在一系列阶段（源代码、构建、暂存和生产）中进行测试，然后作为生产就绪代码发布。如果您的组织不熟悉 CI/CD，则可以通过迭代方式处理此管道。这意味着您应该从小处着手，在每个阶段进行迭代，以便您能够以可帮助组织发展壮大的方式理解和开发代码。
![\[CI/CD 管道\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image2.png)
*CI/CD 管道*
CI/CD 管道的每个阶段都被构造为交付过程中的一个逻辑单元。此外，每个阶段都充当审查代码某个方面的一道关卡。随着代码在管道中推进，假设代码的质量在后面的阶段会更高（因为代码的更多方面持续得到验证）。在早期阶段发现的问题会阻止代码在管道中推进。测试的结果会立即发送给团队，如果软件没有通过该阶段，所有后续的构建和发布工作都会停止。
这些阶段是建议。您可以根据业务需求调整各个阶段。对于多种类型的测试、安全性和性能，可以重复某些阶段。根据项目的复杂性和团队的结构，某些阶段可以在不同的级别重复多次。例如，一个团队的最终产品可以成为下一个团队的项目中的依赖项。这意味着第一个团队的最终产品随后将作为下一个团队的项目中的构件。
CI/CD 管道的存在将对组织能力的成熟过程产生重大影响。组织应该从小步骤开始，而不是试图建立一个完全成熟的管道（即，一开始就有多个环境、多个测试阶段并在所有阶段都实现自动化）。请记住，即使是拥有高度成熟的 CI/CD 环境的组织，仍需要不断地改进其管道。
建立一个支持 CI/CD 的组织是一个过程，在这一过程中有许多目的地。下一节将讨论您的组织可以采取的一种可能途径，从持续集成开始直至持续交付的各个层面。
# 持续集成
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-source-and-build.png)
*持续集成 — 源代码和构建*
CI/CD 过程的第一阶段是在持续集成中发展成熟度。您应确保所有开发人员定期将其代码提交到中央存储库（例如托管在 CodeCommit 或 GitHub 中的存储库），并将所有更改合并到应用程序的发布分支中。任何开发人员都不应孤立地持有代码。如果在一段时间内需要功能分支，则应通过尽可能频繁地从上游合并以使其保持最新状态。建议团队经常提交内容并与完整的工作单元进行合并，此做法应成为团队的纪律并受到流程鼓励。早期且经常合并代码的开发人员在将来可能会遇到较少的集成问题。
还应该鼓励开发人员尽早为其应用程序创建单元测试，并在将代码推送到中央存储库之前运行这些测试。在软件开发过程早期发现的错误最容易修复，且修复成本最低。
将代码推送到源代码存储库中的分支时，监控该分支的工作流引擎会向构建器工具发送命令，以在受控环境中构建代码并运行单元测试。应适当调整构建过程的规模以处理所有活动，包括提交阶段可能发生的推送和测试，以便快速获得反馈。其他质量检查（例如单元测试覆盖率、样式检查和静态分析）也可以在此阶段进行。最后，构建器工具会为应用程序创建一个或多个二进制版本和其他构件，例如图像、样式表和文档。
# 持续交付：创建暂存环境
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-staging.png)
*持续交付 — 暂存*
持续交付 (CD) 是下一阶段，它需要在作为生产堆栈副本的暂存环境中部署应用程序代码，并运行更多功能测试。暂存环境可以是为进行测试而预构建的静态环境，或者您可以使用已提交的基础设施和配置代码来预置和配置动态环境，以测试和部署应用程序代码。
# 持续交付：创建生产环境
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-production.png)
*持续交付 — 生产*
在部署/交付管道序列中，暂存环境之后是生产环境，该环境也是使用基础设施即代码 (IaC) 构建的。
# 持续部署
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-cd.png)
*持续部署*
CI/CD 部署管道的最后一个阶段是持续部署，这可能包括整个软件发布流程（包括部署到生产环境）的完全自动化。在完全成熟的 CI/CD 环境中，通往生产环境的路径是完全自动化的，这样就可以信心十足地部署代码。
# 成熟度及更多
随着组织日渐成熟，它将继续发展 CI/CD 模式，以包括以下更多改进功能：
+ 提供更多暂存环境，以进行特定的性能、合规性、安全性和用户界面 (UI) 测试
+ 基础设施和配置代码以及应用程序代码的单元测试
+ 与其他系统和流程（如代码审查、问题跟踪和事件通知）集成
+ 与数据库架构迁移集成（如果适用）
+ 审计和业务批准的其他步骤
即使是拥有复杂的多环境 CI/CD 管道的最成熟组织，也在继续寻求改进。DevOps 是一个过程，而不是一个终点。通过开发团队不同部门之间的协作，不断收集有关管道的反馈，并实现速度、规模、安全性和可靠性方面的改进。
# 团队
AWS 建议组成三个开发人员团队来实施 CI/CD 环境：应用程序团队、基础设施团队和工具团队（请参见下图）。该组织代表了一套最佳实践，这些实践已在快速发展的初创公司、大型企业组织和 Amazon 本身中得以开发和应用。团队规模应不超过两个比萨饼可以承受的人数，或大约 10-12 人。这遵循了一条沟通规则，即随着群体规模的增加和沟通渠道的增多，有意义的对话会达到极限。
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image7.png)
*应用程序、基础设施和工具团队*
## 应用程序团队
应用程序团队创建应用程序。应用程序开发人员拥有待办事项、情节和单元测试，并且根据指定的应用程序目标开发功能。该团队的组织目标是最大限度地减少这些开发人员花在非核心应用程序任务上的时间。
除了具备应用程序语言方面的功能编程技能外，应用程序团队还应具备平台技能并了解系统配置。这将使他们能够专注于开发功能和强化应用程序。
## 基础设施团队
基础设施团队负责编写代码，以同时创建和配置运行应用程序所需的基础设施。该团队可能使用原生 AWS 工具（例如 AWS CloudFormation）或通用工具，例如 Chef、Puppet 或 Ansible。基础设施团队负责指定所需的资源，并与应用程序团队密切合作。对于一个小型应用程序，基础设施团队可能只由一两个人组成。
团队应该具备基础设施预置方法方面的技能，例如 AWS CloudFormation 或 HashiCorp Terraform。团队还应使用 Chef、Ansible、Puppet 或 Salt 等工具来培养配置自动化技能。
## 工具团队
工具团队负责构建和管理 CI/CD 管道。他们负责构成管道的基础设施和工具。他们不是双比萨团队的成员；但是，他们创建的工具可供组织中的应用程序团队和基础设施团队使用。组织需要不断完善其工具团队，以便工具团队比日趋成熟的应用程序团队和基础设施团队领先一步。
工具团队必须能够熟练地构建和集成 CI/CD 管道的所有部分。这包括构建源代码管理存储库、工作流引擎、构建环境、测试框架和构件存储库。该团队可以选择实施 AWS CodeStar、AWS CodePipeline、AWS CodeCommit、AWS CodeDeploy、AWS CodeBuild 和 AWS CodeArtifact 等软件以及 Jenkins、GitHub、Artifactory、TeamCity 和其他类似工具。一些组织可能将其称为 DevOps 团队，但 AWS 不鼓励这样做，而是鼓励将 DevOps 视为软件交付中人员、流程和工具的总和。
# 持续集成和持续交付的测试阶段
这三个 CI/CD 团队应在 CI/CD 管道的不同阶段将测试纳入软件开发生命周期。总体而言，应尽早开始测试。以下测试金字塔是迈克·科恩 (Mike Cohn) 在*《成功与敏捷》* 中提供的概念。它显示了各种软件测试以及相关的成本和运行速度。
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image8.png)
*CI/CD 测试金字塔*
单元测试位于金字塔的底部。它们既是运行速度最快的，也是成本最低的。因此，单元测试应构成测试策略的重要部分。一个好的经验法则是大约 70％。单元测试应该具有近乎完整的代码覆盖率，因为在此阶段中找到的错误可以快速、低成本修复。
服务、组件和集成测试位于金字塔上单元测试的上方。这些测试需要详细的环境，因此满足基础设施要求的成本更高，运行速度更慢。性能和合规性测试是下一个级别。它们需要生产质量的环境，而且成本更高。用户界面和用户验收测试处于金字塔的顶端，也需要生产质量的环境。
所有这些测试都是确保高质量软件的完整策略的一部分。但是，为了加快开发速度，重点是金字塔下半部分的测试数量和覆盖范围。
以下各节将讨论 CI/CD 阶段。
## 设置源代码
在项目开始时，务必设置可以存储原始代码以及配置和架构更改的源代码。在源代码阶段，选择源代码存储库，例如托管在 GitHub 或 AWS CodeCommit 中的源代码存储库。
## 设置和运行构建过程
构建过程自动化对于 CI 流程至关重要。设置构建过程自动化时，第一项任务是选择正确的构建工具。有许多构建工具，例如：
+ Ant、Maven 和 Gradle for Java
+ Make for C/C\$1\$1
+ Grunt for JavaScript
+ Rake for Ruby
最适合您的构建工具取决于项目的编程语言和团队的技能集。选择构建工具后，需要在构建脚本中明确定义所有依赖项以及构建步骤。对最终的构建构件进行版本化也是一种最佳实践，这样可以更轻松地部署和跟踪问题。
## 构建
在构建阶段，构建工具会将对源代码存储库的任何更改作为输入，构建软件，并运行以下类型的测试：
**单元测试** – 测试代码的特定部分，以确保代码执行预期的功能。单元测试由软件开发人员在开发阶段执行。在此阶段，可以应用静态代码分析、数据流分析、代码覆盖率和其他软件验证过程。
**静态代码分析** – 此测试是在构建和单元测试后不实际执行应用程序的情况下执行的。这种分析可以帮助发现编码错误和安全漏洞，还可以确保符合编码准则。
## 暂存
在暂存阶段，将创建镜像最终生产环境的完整环境。将执行以下测试：
**集成测试** – 根据软件设计验证组件之间的接口。集成测试是一个迭代过程，有助于构建稳健的接口和促进系统完整性。
**组件测试** – 测试在不同组件之间传递的消息及其结果。该测试的一个关键目标可能是组件测试的幂等性。测试可能包括极大的数据量、边缘情况和异常输入。
**系统测试** – 端到端测试系统并验证软件是否满足业务需求。这可能包括测试用户界面 (UI)、API、后端逻辑和结束状态。
**性能测试** – 确定系统在特定工作负载下执行时的响应能力和稳定性。性能测试还用于调查、测量、确认或验证系统的其他质量属性，例如可扩展性、可靠性和资源使用情况。性能测试的类型可能包括负载测试、压力测试和峰值测试。性能测试用于根据预定义的标准进行基准测试。
**合规性测试** – 检查代码更改是否符合非功能规范和/或法规的要求。它确定您是否正在实施且满足定义的标准。
**用户验收测试** – 验证端到端业务流程。此测试由终端用户在暂存环境中执行，并确认系统是否满足要求规范的要求。通常，客户在此阶段会采用 Alpha 和 Beta 测试方法。
## 生产
最后，在通过之前的测试后，将在生产环境中重复暂存阶段。在此阶段，可以通过在将新代码部署到整个生产环境之前，将新代码部署到一小部分服务器甚至一台服务器上，或部署到一个 AWS 区域中，以完成最终 *Canary 测试*。[部署方法](deployment-methods.md)部分介绍了如何安全地部署到生产环境的具体细节。
下一节将讨论构建管道以合并这些阶段和测试。
## 构建管道
本节讨论构建管道。首先建立一个仅包含 CI 所需组件的管道，之后过渡到包含更多组件和阶段的持续交付管道。本节还讨论如何考虑对大型项目使用 AWS Lambda 函数和手动批准，以及如何针对多个团队、分支和 AWS 区域进行规划。
# 从最简可行管道开始，以实现持续集成
您的组织实现持续交付的旅程始于最简可行管道 (MVP)。正如[实施持续集成和持续交付](implementing-continuous-integration-and-continuous-delivery.md)中所讨论，团队可以从一个非常简单的流程开始，例如实施一个管道，以执行代码样式检查或在不进行部署的情况下执行单个单元测试。
一个关键组件是持续交付编排工具。为了帮助您构建此管道，Amazon 开发了 [AWS CodeStar](https://aws.amazon.com/codestar)。
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/aws-codestar-setup.png)
*AWS CodeStar 设置页面*
AWS CodeStar 将 AWS CodePipeline、AWS CodeBuild、AWS CodeCommit 和 AWS CodeDeploy 与集成的设置流程、工具、模板和控制面板结合使用。AWS CodeStar 提供了您在 AWS 上快速开发、构建和部署应用程序所需的一切。这让您可以更快地开始发布代码。已经熟悉 AWS 管理控制台并寻求更高级别控制的客户可以手动配置他们选择的开发工具，并可以根据需要预置各项 AWS 服务。
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codestar-dashboard.png)
*AWS CodeStar 控制面板*
AWS CodePipeline 是一项 CI/CD 服务，可通过 AWS CodeStar 或通过 AWS 管理控制台使用，以进行快速、可靠的应用程序和基础设施更新。在每次代码发生更改时，AWS CodePipeline 都会根据您定义的发布流程模型构建、测试和部署代码。这使您能够快速而可靠地提供各种功能和更新。您可使用我们提供的针对常用第三方服务（如 GitHub）的预先构建的插件，或通过将您的自定义插件集成到您发布流程中的任何阶段，来轻松构建端到端解决方案。使用 AWS CodePipeline，您只需按实际使用量付费。无需预付费用或长期承诺。
AWS CodeStar 和 AWS CodePipeline 的步骤直接映射到[源代码、构建、暂存和生产 CI/CD 阶段](testing-stages-in-continuous-integration-and-continuous-delivery.md)。虽然需要持续交付，但您可以从一个简单的两步管道开始，此管道检查源代码库并执行构建操作：
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-source-build.png)
* AWS CodePipeline — 源代码和构建阶段*
对于 AWS CodePipeline，源代码阶段可以接受来自 GitHub、AWS CodeCommit 和 Amazon Simple Storage Service (Amazon S3) 的输入。自动执行构建流程是实施持续交付并迈向持续部署的关键性的第一步。消除人工参与生成构建构件过程可以减轻团队的负担，最大限度地减少因手动打包而引入的错误，并允许您更频繁地开始打包可使用的构件。
AWS CodePipeline 与 AWS CodeBuild 这一完全托管式构建服务无缝协作，以便更轻松地在管道中设置用于打包代码和运行单元测试的构建步骤。使用 AWS CodeBuild，您无需预置、管理或扩展自己的编译服务器。AWS CodeBuild 可以持续扩展并同时处理多项构建任务，因此您的构建任务不会在队列中等待。AWS CodePipeline 还与 Jenkins、Solano CI 和 TeamCity 等编译服务器集成。
例如，在接下来的构建阶段，三个操作（单元测试、代码样式检查和代码指标收集）并行运行。使用 AWS CodeBuild，可以将这些步骤添加为新项目，而无需进一步构建或安装编译服务器来处理负载。
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-build-functionality.png)
*AWS CodePipeline – 构建功能*
图（*AWS CodePipeline — 源代码和构建阶段*）中所示的源代码和构建阶段以及支持流程和自动化可为团队向持续集成过渡提供支持。在这个成熟度级别上，开发人员需要定期关注构建和测试结果。他们还需要培育和维护一个正常运行的单元测试基地。这反过来又会增强整个团队对 CI/CD 管道的信心，并进一步推动对它的采用。
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-stages.png)
* AWS CodePipeline 阶段*
# 持续交付管道
实施持续集成管道并建立支持流程后，您的团队就可以开始向持续交付管道过渡。这种过渡要求团队自动执行构建和部署应用程序的过程。
持续交付管道的特点是存在暂存和生产步骤，其中生产步骤是在人工批准后执行的。
与构建持续集成管道的方式相同，您的团队可以通过编写部署脚本逐步开始构建持续交付管道。
根据应用程序的需要，某些部署步骤可以由现有 AWS 服务抽象出来。例如，AWS CodePipeline 直接与以下服务集成：AWS CodeDeploy（自动将代码部署到 Amazon EC2 实例和本地运行的实例的服务）；AWS OpsWorks（可帮助您使用 Chef 操作应用程序的配置管理服务）；以及 AWS Elastic Beanstalk（用于部署和扩展 Web 应用程序和服务的服务）。
AWS 提供了详细的[文档](https://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-w.html#getting-started-w-create-deployment)来介绍如何实施 AWS CodeDeploy 并将其与基础设施和管道集成。
在团队成功实现了应用程序部署自动化之后，可以通过各种测试来扩展部署阶段。例如，您可以添加其他与 Ghost Inspector、Runscope 等服务的开箱即用集成，如下图所示。
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-code-test-deployment.png)
*AWS CodePipeline – 部署阶段的代码测试*
# 添加 Lambda 操作
AWS CodeStar 和 AWS CodePipeline 支持[与 AWS Lambda 集成](https://docs.aws.amazon.com/codepipeline/latest/userguide/how-to-lambda-integration.html)。这种集成支持实施一系列广泛的任务，例如在环境中创建自定义资源、与第三方系统（如 Slack）集成，以及对新部署的环境执行检查。
可以在 CI/CD 管道中使用 Lambda 函数来执行以下任务：
+ 通过应用或更新 AWS CloudFormation 模板来实施对环境所做的更改。
+ 使用 AWS CloudFormation 在管道的一个阶段按需创建资源，并在另一个阶段将其删除。
+ 使用将交换[规范名称记录](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) (CNAME) 值的 Lambda 函数，在 AWS Elastic Beanstalk 中部署零停机时间的应用程序版本。
+ 部署到 Amazon Elastic Container Service (ECS) Docker 实例。
+ 通过创建 AMI 快照在构建或部署之前备份资源。
+ 将与第三方产品的集成添加到您的管道中，例如将消息发布到 Internet Relay Chat (IRC) 客户端。
# 手动批准
您可以在管道内的某个阶段中您希望管道处理停止的位置添加批准操作，以便拥有所需 AWS Identity and Access Management (IAM) 权限的人可以批准或拒绝该操作。
如果操作获得批准，管道处理将恢复。如果该操作被拒绝，或者没有人在管道到达该操作并停止的七天内批准或拒绝该操作，结果将与操作失败的结果相同，并且管道处理不会继续。
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codedeploy-manual-approvals.png)
*AWS CodeDeploy— 手动批准*
# 在 CI/CD 管道中部署基础设施代码更改
AWS CodePipeline 可让您在管道的任何阶段选择 AWS CloudFormation 作为部署操作。然后，您可以选择您希望 AWS CloudFormation 执行的特定操作，例如创建或删除堆栈以及创建或执行[更改集](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3952)。[堆栈](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3929)是一个 AWS CloudFormation 概念，代表一组相关的 AWS 资源。虽然有许多方法可以预置基础设施即代码，但 AWS CloudFormation 是 AWS 推荐的综合工具，它是一种可扩展、完整的解决方案，可以将最全面的 AWS 资源集描述为代码。AWS 建议在 AWS CodePipeline 项目中使用 AWS CloudFormation，以[跟踪基础设施更改和测试](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/continuous-delivery-codepipeline.html)。
# 适用于无服务器应用程序的 CI/CD
还可以使用 AWS CodeStar、AWS CodePipeline、AWS CodeBuild 和 AWS CloudFormation 为无服务器应用程序构建 CI/CD 管道。无服务器应用程序将 [Amazon Cognito](https://aws.amazon.com/cognito)、Amazon S3 和 Amazon DynamoDB 等托管式服务与事件驱动型服务以及 AWS Lambda 集成，以不需要管理服务器的方式部署应用程序。如果您是无服务器应用程序开发人员，则可以使用 AWS CodePipeline、AWS CodeBuild 和 AWS CloudFormation 的组合来自动构建、测试和部署在使用 AWS Serverless Application Model 构建的模板中表示的无服务器应用程序。有关更多信息，请参阅[自动部署基于 Lambda 的应用程序](https://docs.aws.amazon.com/lambda/latest/dg/automating-deployment.html)的 AWS Lambda 文档。
还可以使用 AWS Serverless Application Model Pipelines (AWS SAM Pipelines) 创建遵循组织最佳实践的安全 CI/CD 管道。AWS SAM Pipelines 是 AWS SAM CLI 的一项新功能，能够让您在几分钟内获得 CI/CD 的益处，例如加快部署频率、缩短实施更改所需的时间以及减少部署错误。AWS SAM Pipelines 附带了一组适用于 AWS CodeBuild/CodePipeline 的原定设置管道模板，这些模板遵循 AWS 部署最佳实践。有关更多信息并要查看教程，请参阅博客 [AWS SAM Pipelines 简介](https://aws.amazon.com/blogs/compute/introducing-aws-sam-pipelines-automatically-generate-deployment-pipelines-for-serverless-applications/)。
# 适用于多个团队、分支和 AWS 区域的管道
对于大型项目，多个项目团队处理不同组件的情况并不少见。如果多个团队使用单个代码存储库，则可以对其进行映射，以便每个团队都有其自己的分支。还应该有一个集成或发布分支进行项目的最终合并。如果使用面向服务的架构或微服务架构，则每个团队都可以拥有自己的代码存储库。
在第一种情况下，如果使用单个管道，则一个团队可能会通过阻塞管道来影响其他团队的进度。AWS 建议您为团队分支创建特定的管道，并为最终产品交付创建另一个发布管道。
# 管道与 AWS CodeBuild 的集成
AWS CodeBuild 旨在使您的组织能够构建具有几乎无限规模的高可用性构建流程。AWS CodeBuild 为多种常用语言提供了快速入门环境，并能够运行您指定的任何 Docker 容器。
凭借与 AWS CodeCommit、AWS CodePipeline 和 AWS CodeDeploy 紧密集成的优势以及 Git 和 CodePipeline Lambda 操作，CodeBuild 工具非常灵活。
可以通过包含一个 `buildspec.yml` 文件来构建软件，该文件标识每个构建步骤，包括构建前和构建后操作或通过 CodeBuild 工具指定的操作。
可以使用 CodeBuild 控制面板查看每个构建操作的详细历史记录。事件以 Amazon CloudWatch Logs 日志文件的形式存储。
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cloudwatch-logs-log-files.png)
*AWS CodeBuild 中的 CloudWatch Logs 日志文件*
# 管道与 Jenkins 的集成
可以使用 Jenkins 构建工具[创建交付管道](https://www.jenkins.io/doc/book/pipeline/getting-started/)。这些管道使用标准任务，而这些任务定义用于实施持续交付阶段的步骤。但是，对于较大的项目，这种方法可能不是最佳选择，因为管道的当前状态不会在 Jenkins 重启之间持续存在，实现手动批准并不简单，而且跟踪复杂管道的状态可能很复杂。
相反，AWS 建议您使用 [AWS Code Pipeline 插件](https://wiki.jenkins-ci.org/display/JENKINS/AWS+CodePipeline+Plugin)通过 Jenkins 实现持续交付。该插件允许使用类似 Groovy 的域特定语言来描述复杂的工作流，并可用于编排复杂的管道。AWS Code Pipeline 插件的功能可以通过使用附属插件来增强，例如 [Pipeline Stage View](https://plugins.jenkins.io/aws-codepipeline/) 插件（用于直观展示在管道中定义的阶段的当前进度）或 [Pipeline Multibranch 插件](https://plugins.jenkins.io/workflow-multibranch/)（对来自不同分支的构建进行分组）。
AWS 建议您将管道配置存储在 *Jenkinsfile* 中，并将其签入到源代码存储库中。这样，就可以跟踪对管道代码的更改，在使用 Pipeline Multibranch 插件时这会变得更加重要。AWS 还建议您将管道划分为多个阶段。这会对管道步骤进行逻辑分组，并使 Pipeline Stage View 插件能够直观展示管道的当前状态。
下图显示一个 Jenkins 管道示例，其中包含由 Pipeline Stage View 插件直观展示的四个已定义阶段。
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/defined-stages-of-jenkins.png)
*由 Pipeline Stage View 插件直观展示的 Jenkins 管道的四个已定义阶段*