拥抱 DevOps 发布管理——理解 CI/CD 的基础知识

持续集成和持续交付（CI/CD）是DevOps发布管理中的关键策略。它自动化了传统上需要人工干预的大部分工作，以便生成新的软件版本或将新代码投入生产。CI/CD包括集成测试、单元测试、回归测试以及构建和部署阶段。基础设施即代码（Infrastructure as Code）也可以集成到CI/CD流程中，自动化云基础设施的配置，甚至可以包括本地虚拟基础设施的配置。通过CI/CD流水线，软件开发团队可以对代码进行更改，随后自动进行测试、交付并在任何环境中部署。如你所见，CI/CD显著减少了停机时间，确保发布速度更快、从版本到版本的一致性更高，而且发布频率也大幅增加。非常棒的一个变革！

你可以定制流水线来完成各种任务，即使这些任务与发布软件无关。这可能包括为业务部门生成报告，在非高峰时段关闭未使用的基础设施并在下一个工作日开始前重新启动，从生产环境中刷新开发数据库，针对网络基础设施执行自动化渗透测试，自动轮换IAM密钥、SSL证书等等！关于CI/CD的优秀资料很多，但对于本书的主题，提及它是必不可少的。

在第六章中，你将学习以下内容：

• CI/CD的基础知识
• 什么是持续集成（CI）
• 什么是持续交付（CD）
• 什么是持续测试
• Capital One的DevOps转型

在本章结束时，你将学到CI/CD的核心原则、其诞生的理念以及实施它的基本策略。虽然本章不会深入探讨CI/CD的技术实现，但你将看到一些能够帮助你取得成功的策略性方法，以及一些有助于实现这些目标的工具。

CI/CD 的基础知识

CI/CD 是当今软件行业的命脉，推动了新程序的快速创建和分发。消除集成和交付瓶颈的工具对于任何 CI/CD 流水线的顺利运行至关重要。团队需要使用一套统一的技术，以便在项目上协作高效地工作。源代码控制、测试工具、基础设施修改和监控工具只是可以通过这个框架统一的 SDLC 元素之一。

通过精心架构的 CI/CD 流水线，企业可以迅速适应消费者需求的新趋势和技术进步。相比之下，使用传统开发策略的团队需要花费很长时间才能实现客户请求的更改或整合新技术。此外，当公司意识到需要转型时，消费者的需求可能已经发生了变化。DevOps 发布管理通过采用持续集成和持续部署来解决这一问题，持续部署是持续交付的一个稍微高级的版本，我们将在后面详细讨论。

什么是 CI/CD 流水线？

CI/CD 流水线简化了软件或基础设施即代码交付的自动化过程，确保了从源代码到生产部署的顺利过渡。你可以将它看作是代码发布所需的一系列步骤。CI 是持续集成（Continuous Integration）的缩写，而 CD 是持续交付（Continuous Delivery）或持续部署（Continuous Deployment）的缩写。流水线的概念涉及自动化交付工作流程的各个阶段，包括构建、测试、交付和部署。通过自动化和控制交付过程的每个阶段，可以充分利用 CI/CD 流水线的所有优势，这有助于最大限度地减少人为错误，并确保每次发布的一致性。

CI/CD 流水线通常配置为代码，因此广泛被称为流水线即代码（Pipeline as Code）。为了便于流水线的运行，通常使用 CI 服务器及其相应的构建代理（Build Agent）。根据你使用的产品，构建代理可能被称为运行器（Runner）。通常，构建代理以虚拟机的形式出现，可以自托管并完全自定义，且需要定期维护。或者，如果你使用的是商业 SaaS 产品，你可以使用 SaaS 提供的 CI 服务器和构建代理，但在自定义和添加软件或插件时可能会受到限制。

容器也可以用来创建一致的构建环境，减少维护静态构建代理的需求。在这种情况下，CI/CD 流水线的每个阶段都可以在一个根据其特定需求量身定制的容器中独立运行。此外，流水线还可以利用容器编排提供的各种好处，包括不变性和按需扩展。

精心设计的 CI/CD 流水线基础设施应该能够接受参数，并在任何数量的环境中产生可重复的结果。它们还具有适应性，例如在现有的 DevOps 解决方案无法满足的消费者需求情景下，可以快速识别解决方案，对其进行分析、开发，并在相对较短的时间内部署到应用环境中——这一切都不会中断应用的正常开发流程。

此外，CI/CD 允许对最终产品进行快速部署，即使是细微的更改也能迅速响应用户请求。这不仅解决了用户的顾虑，还让用户能够了解设计和创建过程。随着更新的推出，修复漏洞和增加新功能，用户将注意到产品随着时间的推移不断改进。与传统方法（如瀑布模型）不同，后者在开发过程的最后阶段才涉及用户，DevOps 发布管理在产品生命周期中促进了持续反馈和改进。

不同的项目对 CI/CD 流水线的复杂性和步骤数量有不同的要求。一个可能的流水线可能采用多阶段部署方法，将软件作为容器分发到跨多个云环境的 Kubernetes 集群中。相反，另一个流水线可能采用更简单的方法，构建、测试和部署一个在虚拟机上运行并位于代理服务器后的 .jar 文件应用程序。在这个例子中，这两个流水线的共同目标都是自动化软件交付过程。

简而言之，建立良好架构的 CI/CD 流水线基础设施对于充分利用 DevOps 发布管理带来的所有好处至关重要。在接下来的部分中，我们将更深入地探讨持续集成的主题。我们将讨论 CI 的含义、为你的组织选择合适的 CI 工具、示例流水线语法以及功能对比。

什么是持续集成（CI）？

现代软件开发离不开持续集成（CI）。现代软件的创建通常涉及众多地理位置分散的开发人员的合作，每个人都专注于产品的特定组件、功能或方面。为了发布一个完整的产品，必须合并所有这些代码更改。然而，手动合并所有这些更改是极不切实际的，是一项艰巨的任务，而且当开发人员同时处理多个更新时，不可避免地会出现代码冲突。然而，持续集成鼓励开发人员不断将他们的代码推送到同一个版本控制系统（VCS），这种策略提供了一种解决这一问题的巧妙协同方式。通过使用 CI，你可以持续提交、构建和测试团队的代码，这对于 DevOps 发布经理来说是一项至关重要的策略。如果你的团队经常测试新代码，他们将能够在缺陷深植于软件之前发现并修复它们。

虽然 CI 没有硬性规定必须使用哪些工具，但许多团队更喜欢使用持续集成服务器，如 Jenkins、GitLab CI 或 GitHub Actions。当有新的代码更改提交时，持续集成服务器会监督一切，充当仲裁者。每次开发人员在代码库中提交他们的工作时，CI 服务器都会自动运行一套测试并记录结果。通常，进行更改的开发人员会在提交后不久收到测试结果的电子邮件。这一点非常重要，因为它可以让开发人员在最短的时间内解决潜在的问题。

在更改通过自动化测试后，更新的代码可以获得批准，以创建新的构建并在 QA 和预生产环境中进行额外的测试。如果所有质量检查都通过，代码就可以合并到主分支，并发布新的版本。单元测试和集成测试通常作为持续集成过程的一部分进行，以确保代码更改不会导致稳定性问题。此外，CI 也是集成静态应用安全测试（SAST）的理想场所，将应用安全性移动到开发周期的初期阶段。所有这些测试自动化确保了在将代码推广到生产环境之前，对代码所做的任何更改都经过充分验证。

增加提交频率的另一个好处是，单个贡献者可以更早地主动检测和解决合并冲突，或者尽量减少其发生，或者完全避免它们。此外，集成较小的工作增量是一种有效的方式，可以避免一次性提交大量更改并遇到难以解决的错误；相反，开发人员将会生成较少的代码，总行数更少。这使得识别和解决代码中的错误和缺陷的任务更加高效，将所需时间从数小时减少到几分钟。

选择合适的 CI 工具

在为团队的运营选择合适的 CI/CD 工具时，有众多选项可供选择。评估你自身的独特需求和偏好至关重要，因为每种工具都有其优点和缺点，这可能会影响你的成功。不论你偏好开源选项、人工智能能力、本地部署解决方案、峰值可扩展性或广泛的自定义功能，都可以找到满足你需求的工具。

在评估团队的各种 CI/CD 工具时，你应该考虑以下核心因素，然后再决定选择哪一个：

• 本地部署与云端：评估工具是否提供基于云端和/或本地（托管）的解决方案，并选择最适合项目需求的选项。
• 开源与闭源：考虑 CI/CD 工具与开源项目的兼容性，以及它与项目目标的契合度。
• 测试集成：建议选择一个具有用户友好界面且配置易于理解的 CI/CD 工具，以尽量减少设置困难。
• 设置和配置的简易性：你应该选择一个界面友好且配置易于理解的 CI/CD 工具，减少设置的复杂性。
• 构建环境兼容性：考虑工具与项目环境和编程语言的兼容性，以简化集成过程。
• 学习曲线：建议考虑开发人员可能面临的学习曲线，以便于构建和部署工作流程的设置和配置。
• 付费计划功能：为了应对项目的增长，建议检查付费计划（如果有）中提供的现有功能和新功能，包括每日构建次数、运行时间、用户数量和私有代码库数量等。
• 版本控制系统兼容性：确保验证 CI/CD 工具是否能够与首选的版本控制系统或源代码管理平台顺利集成，以实现高效的源代码管理和交付。

接下来，我们将深入探讨行业领先的三大 CI/CD 工具，帮助你评估哪个工具最适合你的企业。首先，Jenkins 是一个知名的 CI 服务器，历史悠久，提供了许多功能插件，这些插件是较新竞争对手所不具备的。另一个强大的工具是 GitLab CI，它与 GitHub 代码库的集成非常优雅。不要忽视 GitHub Actions，它提供了一个简单易懂的工作流程。

Jenkins

Jenkins 是一个知名且高度可定制的开源 CI/CD 工具，几乎可以自动化任何任务。Jenkins 是用 Java 编程语言开发的，并以 MIT 许可证的形式开源发布。该软件提供了一系列全面的功能，简化了各种任务，包括构建、测试、部署、集成和发布软件。Jenkins 服务器（Master）软件兼容 Linux、macOS、Windows 和 Unix。除了通过本机安装包进行安装外，Jenkins 还可以作为独立的 Docker 容器运行，或在任何安装了 Java 运行时环境（JRE）的机器上运行。

Jenkins Master 负责监督和协调整个构建过程，充当仲裁者。它是配置设置、作业定义和元数据的中心，掌握着完全的控制权。这里可以安装各种插件，扩展 Jenkins 的功能和能力，例如与 Atlassian JIRA 或 SonarSource SonarQube 的集成。此外，Jenkins Master 提供了一个易于使用的基于 Web 的界面，允许用户与 Jenkins 交互，设置作业，并跟踪构建进度。

然而，系统中的任意数量的 Slave 节点则是勤奋的工人。在 Master 的直接监督下，它们执行分配的任务。通过将任务分配给多个 Slave，构建流水线可以通过并行处理更快地完成。此外，Slave 可以配置在不同的机器上，包括各种操作系统和环境。由于这种多样性，Jenkins 可以满足各种构建和测试需求。

此外，Jenkins 团队开发了一个名为 Jenkins X 的子项目，该项目专注于在 Kubernetes 中无缝运行流水线，几乎不需要额外工作。Jenkins X 无缝结合了 Helm、Jenkins CI/CD 服务器、Kubernetes 和各种其他工具，提供了一条具有预先确立的最佳实践的精简 CI/CD 流水线，例如采用 GitOps 来管理环境。

Jenkins语法示例

现在，让我们来看一个 Jenkins 流水线的示例，以便实际理解其语法及其配置方式！在 Jenkinsfile 文件中，构建了一个 Docker 容器镜像，并将生成的工件发布到指定的 Docker 注册表中：

GitLab CI

在所有可用的 CI/CD 工具中，GitLab CI/CD 脱颖而出，成为最新且最受推崇的选择。该产品是一个自托管的持续集成工具，其社区版完全免费使用。

GitLab CI/CD 包含一系列功能，如 git 代码库管理、问题跟踪、代码审查、维基和活动源。公司通常选择在本地安装 GitLab CI/CD，并将其与组织的 Active Directory 和 LDAP 服务器连接，以确保安全的授权和身份验证。使用 GitLab 社区版的一个明显缺点是缺乏任何形式的客户支持。如果遇到挑战或需要项目帮助，你无法像使用其他两个版本（Premium 和 Ultimate）那样提交工单并请求帮助。

从社区版升级到 Ultimate 或 Premium 版本，可以获得客户支持，以及许多有利的安全功能，如双因素身份验证、先进的安全扫描和代码的合规审计工具。此外，还可以访问各种辅助工具，包括推送规则、DORA 指标跟踪、燃尽图、安全扫描 IDE 集成和动态应用安全测试（DAST）功能。通过利用高级监控功能，如性能指标和系统健康检查，可以确保项目在没有额外风险的情况下持续运行。

GitLab 服务器负责检测触发事件，启动一个或多个流水线。当新的流水线开始时，GitLab 服务器会确定应运行哪些作业（定义在你的 .gitlab-ci.yml 文件中），必要时跳过一些作业并将其他作业排队。这些作业然后按正确顺序分配给可用的运行器（Runners）。

上图所示的 GitLab 架构由以下组件组成：

• 提交（Commit） ：提交是对文件或代码进行的更改记录，类似于 GitHub 代码库中的内容。
• 作业（Jobs） ：作业是 GitLab 流水线需要执行的单个任务，例如部署应用程序。每个任务都分配了一个名称并包含一个脚本。每个脚本按顺序执行，确保在继续下一个任务之前完成每个作业。
• 阶段（Stages） ：阶段是不同任务之间的明确区分，表示流水线每个步骤的进展情况。这明确了任务应执行的顺序。作为示例，阶段可以包括测试、构建和部署。
• 流水线（Pipeline） ：流水线是一个综合的阶段集合，每个阶段由一个或多个任务组成。GitLab 提供了多种流水线选项，如基本、合并、父子和多项目流水线。
• 运行器（Runners） ：运行器是负责执行 CI/CD 流水线的活动组件。你可以选择在本地设置自托管的 GitLab 运行器，或者使用 GitLab 提供的 GitLab.com 上的 SaaS 产品中的运行器。
• GitLab 服务器：GitLab 服务器处理和管理你的流水线配置。你可以在本地设置自己的 GitLab 服务器实例，或者使用托管在 GitLab.com 上的 SaaS 版本。

GitLab CI 语法示例

现在，让我们来看一个 GitLab CI/CD 流水线的示例，以便实际理解其语法及其配置方式！在 .gitlab-ci.yml 文件中，构建了一个 Docker 容器镜像，并将生成的工件发布到指定的 Docker 注册表中：

GitHub Actions

GitHub Actions 是 GitHub 流程中用于持续集成和持续部署的工具。它可以用于将代码更改集成和部署到第三方云应用平台，以及测试、跟踪和管理代码更改。GitHub Actions 兼容各种第三方 CI/CD 工具、Docker 容器生态系统和其他自动化技术。

GitHub Actions 通过事件驱动的触发器，将自动化无缝集成到 GitHub 上的软件开发生命周期中。这些触发器是可以指定的事件，范围从创建拉取请求到在代码库中构建新分支等。GitHub Actions 的自动化通过工作流进行管理，这些工作流是位于代码库 .github/workflows 目录中的 YAML 文件。这些工作流定义了自动化过程，在概念上类似于 Jenkins 中的 Jenkinsfile 文件或 GitLab CI/CD 中的 .gitlab-ci.yml 文件。

每个工作流由几个核心概念组成：

• 事件（Events） ：事件是启动工作流的定义触发器。开发人员可以配置它们以搜索一个或多个触发器，然后进行相应调整。此外，还可以配置它们以在 GitHub 上指定的代码库的特定分支上执行。
• 作业（Jobs） ：作业由在单个运行器上执行的一系列顺序任务组成。每个任务都在自己的虚拟机（VM）中操作，并与其他任务并行运行，除非另有声明。
• 步骤（Steps） ：步骤是在作业中执行命令的独立操作。这些步骤可以是操作或 shell 命令。作业中的每一步都在同一运行器上执行。
• 操作（Actions） ：操作是指在运行器上执行的命令，是 GitHub Actions 的基本组成部分，也是其名称的来源。
• 运行器（Runners） ：运行器是 GitHub Actions 的服务器。该程序积极监视可用任务，并行执行这些任务，并提供进度、日志和结果的更新。运行器可以托管在 GitHub 上，也可以托管在自托管的本地服务器上。GitHub 托管的运行器使用 Ubuntu、Linux、Windows 和 macOS 作为其底层操作系统。

使用 GitHub 原生 CI/CD 工具的主要优势在于其简便性。如果你已经在 GitHub 上托管了一个项目，你可以利用内置的 CI/CD 工具，因为它与代码库完全集成。CI/CD 流水线可能相当复杂，涉及广泛的工具来测试应用程序、集成测试、容器平台和应用平台等组件。GitHub Actions 通过与 NodeJS 和 Docker 的无缝集成简化了整个过程。值得注意的是，它使你能够快速选择所需的依赖项版本，并轻松地将代码连接到所需的环境和部署平台。与其他自动化工具和功能不同，GitHub Actions 超越了测试、构建和部署的典型应用，而是提供了自动化任何 webhook 的灵活性。

GitHub Actions 工作流语法示例

现在，让我们来看一个 GitHub Actions 流水线的示例，以便实际理解其语法及其配置方式！在 GitHub Actions 工作流文件中，构建了一个 Docker 容器镜像，并将生成的工件发布到指定的 Docker 注册表中：

既然我们已经建立了对这三种工具的语法差异的基本理解，接下来让我们比较一下这三种 CI 工具的功能。

三种 CI 工具的功能对比

以下表格对行业领先的三种 CI 工具——Jenkins、GitLab CI/CD 和 GitHub Actions 的功能和优点进行了并列比较。此信息旨在帮助你根据自身独特的需求和偏好评估哪种工具最适合你的运营。

功能	Jenkins	GitLab CI/CD	GitHub Actions
本地部署（自托管）	是	是	仅限运行器（Runners）
基于云端	否	是	是
开源	是	是	否
闭源	否	是	是
测试集成	是	是	是
设置和配置的简易性	困难	中等	简单
构建环境兼容性	Linux、Windows、macOS、Unix	Linux、Windows、macOS	云 SaaS
语言支持	任何现代编程语言	C、C++、C#、Go、Java、JavaScript、PHP、Python、Ruby、Scala、TypeScript 等	C、C++、C#、Java、JavaScript、PHP、Python、Ruby、Scala、TypeScript
学习曲线	困难	中等	简单
付费计划功能	否	是	是
版本控制系统兼容性	Git、Mercurial (hg)、Subversion (svn)、Perforce (p4)、ClearCase、Microsoft TFS	Git	Git

表 6.1：Jenkins、GitLab 和 GitHub Actions 的功能对比

代码集成、自动化构建和集成测试是持续集成的三大支柱。持续集成过程的最终目标是生成可部署的工件。这部分关于持续集成和 CI 工具的讨论到此结束。在下一部分中，我们将讨论持续集成的对应概念——持续交付。

什么是持续交付（CD）？

持续交付（CD）是指将代码更改自动准备好以发布和部署到生产环境中的过程。持续交付是 DevOps 发布管理的一个重要组成部分，通常与持续集成（CI）一起使用。

即使在软件开发生命周期（SDLC）的末期，开发人员也可以借助 CI/CD 流水线和版本控制系统（VCS）成功地部署大多数产品代码版本。持续交付使程序员能够在将代码更改发布给客户之前，通过多种方式（不仅仅是单元测试）自动测试代码更改。通过这种方式，开发人员可以对他们部署的构建工件的质量充满信心，因为这些工件将经过严格的测试，并符合行业标准。API 测试、负载测试、功能和 UI 测试、集成测试、合规性测试等，都是在此阶段通常进行的适当类型的测试。

因此，在新的软件发布被允许进入生产环境之前，软件开发人员可以快速评估是否存在错误和缺陷。值得注意的是，持续交付通常包括多阶段部署的执行，其中工件会在不同阶段之间进行过渡，包括 QA、预生产环境，最终到达生产环境。在每个阶段通常都会执行额外的测试和验证步骤，以确保交付工件的可靠性和合法性。发布后的验证程序和部署监控可以（也应该）实施，以进一步增强软件发布的可靠性和韧性。

持续交付不仅承担应用程序部署的责任，还包括进行配置修改、监控应用程序性能以及确保其持续维护。在这里，将灾难恢复（DR）构建到流水线设计中变得至关重要。这是因为持续交付有可能通过包括可能涉及基础设施管理的操作任务来扩展其功能范围。这些任务可以使用专门为此目的设计的基础设施即代码（IaC）和配置即代码（CaC）工具来实现。

什么是基础设施即代码（IaC）？

在技术领域中，“基础设施”这一术语通常与物理组件相关联，例如机架式服务器、网络系统和数据中心。然而，由于云计算的普及，这些基础设施已经超越了其物理限制，转变为可以快速创建、修改和撤销的虚拟服务和环境。在这个新时代，如何高效且可靠地管理和配置这些动态资源成为了一个重大挑战。在此背景下，IaC 的概念变得尤为重要。IaC 工具通过允许通过代码而非手动流程来管理基础设施，简化了构建和维护虚拟 IT 基础设施的工作，提升了一致性，降低了错误风险，并实现了自动化和可扩展性。

因此，在 IaC 的背景下理解幂等性这一概念至关重要。当执行 IaC 部署时，它确保目标环境的配置始终如一，无论其初始状态如何。换句话说，幂等性可以通过两种方法实现：自动配置当前目标环境或将其丢弃并从头开始创建一个新的目标环境。

幂等性（Idempotency）

幂等性在数据管道中指的是能够多次执行相同操作而不会改变初始应用之外的结果。这一特性在分布式系统中特别重要，确保了系统的一致性和可靠性。

值得注意的是，IaC 已经成为解决发布流水线和虚拟化部署环境中配置漂移问题的主要解决方案。没有 IaC，团队将需要手动管理每个环境和部署配置。以这种方式操作，随着时间的推移，每个环境不可避免地会发展出自己独特的配置，这种配置无法自动复制。因此，由于不同环境（如开发、QA、预生产和生产环境）中的不一致性，可能会出现部署问题。由于依赖手动流程，基础设施的管理和维护变得困难、容易出错且难以监控。

配置漂移（Configuration Drift）

配置漂移是指 IT 系统的配置随时间逐渐发生变化。漂移通常在未经适当文档记录或批准的情况下对软件、硬件或操作系统进行修改时无意间发生。它可能影响系统某部分或整个系统的安全性和效率。应用程序故障、停机时间、开发生命周期延长、IT 工单激增、安全漏洞、审计罚款、合规性失败等，都是配置漂移的直接后果。

相反，基础设施即代码利用 DevOps 方法和版本控制的优势，有效地定义和部署各种基础设施组件，包括网络、虚拟机、负载均衡器、DNS、无服务器部署、身份访问管理等。你可以将 IaC 视为软件定义的基础设施。与相同的源代码始终生成具有相同功能的二进制文件类似，IaC 模型在每次部署时始终生成相同的环境。IaC 在当代 DevOps 实践中扮演着至关重要的角色，是持续交付的一个不可或缺的部分。通过使用 IaC，DevOps 团队可以使用一套标准化的方法和资源，无缝协作，高效地在大规模上部署应用程序及其相应的基础设施，确保速度和可靠性。更好的是，IaC 文件可以存储在 Git 中，且易于审计。

为实现这一目标，IaC 通过使用 YAML、JSON 和 HashiCorp 配置语言（HCL）等格式的声明性代码来表示所需的环境状态，从而简化了配置过程并确保一致性。发布流水线使用 IaC 文件，并应用环境描述和版本化的配置模型来设置目标环境，这些环境高度可靠，消除了因配置不一致或缺少依赖关系而引发的运行时问题。关键在于，这使团队能够编辑源代码而不是直接更改目标环境。

为了自动化这些任务，已经开发了几种流行的工具。在接下来的小节中，我们将详细介绍其中四种最常见的工具：Terraform、Pulumi、Ansible 和 Puppet。

Terraform

Terraform 是一个强大的基础设施即代码工具，它允许你使用易于理解的 HCL 编写配置文件来定义云和本地资源。这些文件可以进行版本控制、重用和共享，使其成为管理基础设施的便捷选择。你可以应用简化的工作流程，在生命周期的每个阶段准确地建立和控制基础设施。

Terraform 被设计用于管理广泛的组件，从低级别的计算、存储和网络资源，到更高级别的 DNS 条目、Kubernetes 集群和 SaaS 功能。Terraform 无缝集成了 GitLab、GitHub Actions 和 Jenkins 等流行的持续集成和部署系统。通过这个解决方案，你可以优化从代码到生产的整个部署和管理基础设施的过程。

Terraform 使用基于插件的架构，与包括 AWS、Google Cloud 和 Azure 在内的各种云提供商无缝对接。每个提供商都有一套独特的插件，使 Terraform 能够有效地处理其资源。Terraform 处理用 HCL 编写的配置文件，并生成需要创建或修改的资源的依赖图。然后，它会执行一个计划，以创建或修改必要的资源，以实现预期状态。Terraform 包含一个状态文件，用于维护当前基础设施的状态。

Terraform 的工作流程非常简单，仅需三个步骤即可有效管理任何类型的基础设施：编写（Write）、规划（Plan）、应用（Apply）。Terraform 的三步流程是管理任何类型基础设施最简单的工作流程之一。它允许用户根据特定需求和实施风格自定义工作流程。为了说明 Terraform 的工作原理，让我们来看一个用于在 AWS 中创建 EC2 实例的 Terraform 计划示例：

Pulumi

Pulumi 是一个先进的基础设施即代码（IaC）平台。它利用 TypeScript、JavaScript、Python、Go、.NET、Java 等流行的编程语言，以及 YAML 等标记语言及其相应的生态系统，与云资源无缝交互。Pulumi 的综合平台无缝集成了可下载的 CLI、运行时、库以及托管服务，用于部署虚拟基础设施。这种灵活的组合允许高效地配置、更新和管理云基础设施。

Pulumi 程序使用流行的编程语言编写，概述了云基础设施的组成。当向程序添加新基础设施时，你只需为资源对象分配与所需基础设施状态匹配的属性。这些属性可以用于管理资源之间的依赖关系，如果需要，还可以在堆栈之外导出。

Pulumi 平台由多个组件组成：

• Pulumi 软件开发工具包（SDK） ：为提供商可以管理的每种资源类型提供绑定。这些资源为用户提供了必要的工具和库，以有效定义和管理跨不同提供商和平台的云资源。
• 命令行界面（CLI） ：允许你部署对云应用程序和基础设施的更新。它记录了团队更新的情况，包括贡献者和时间戳。
• 部署引擎：部署引擎计算出必要的操作，以使你的基础设施的当前状态与程序中指定的所需状态一致。

程序存储在项目中，项目是一个包含程序源代码和执行说明的目录。当程序完成后，你可以使用 Pulumi CLI 从项目目录中执行 pulumi up 命令。此命令允许你创建一个独立且可自定义的程序实例，称为堆栈（Stack）。堆栈作为不同的部署环境，用于测试和实施应用程序更新。例如，你可以创建和测试独立的开发、预生产和生产堆栈。

下面是一个示例程序，展示了这些概念。它创建了一个名为 web-sg 的 AWS EC2 安全组，其中包含一个入站规则，以及一个使用该安全组的 t2.micro 规格的 EC2 实例。EC2 资源需要使用安全组的 ID，Pulumi 通过利用安全组资源的输出属性名来实现这一点。Pulumi 深入理解资源依赖关系，使其能够优化并行性，并在创建堆栈时保持正确的顺序。

最后，服务器的 IP 地址和 DNS 名称作为堆栈输出导出，可以通过 CLI 命令或另一个堆栈轻松访问。

Ansible

Ansible 是一个开源的配置管理工具，使用 YAML 定义提供了简化的服务器自动化框架。由于其简化的基础设施要求和用户友好的语法，Ansible 作为配置管理工具获得了极大的普及。

与同类工具（如 Chef 或 Puppet）不同，Ansible 不需要在远程节点上安装任何专门的软件（代理）。只需在控制机器上配置 Ansible 软件，就可以通过标准的 SSH 协议与节点通信，并使用 Python 来执行远程指令。

任务是你可以使用 Ansible 剧本自动化的最小操作单元。剧本通常包含一系列任务，服务于一个目标，例如设置 web 服务器或将应用程序部署到远程环境。Ansible 按照它们在剧本中定义的顺序依次执行任务。在自动化某个过程（例如设置 LAMP 服务器：Linux、Apache、MySQL、PHP）之前，你需要评估哪些手动步骤是必要的，以及完成所有操作的顺序。然后，你可以确定需要哪些任务以及可以使用哪些模块，以更少的步骤实现目标。

此外，Ansible 提供了全面的预构建模块，简化了自动化常规服务器操作的过程。这些模块涵盖了广泛的任务，包括软件包安装、用户管理、文件操作、权限处理和服务管理。

为了展示 Ansible 的工作原理，我们来看一个可以在 AWS 中创建 EC2 实例的 Ansible 剧本示例：

Puppet

Puppet 是一种配置管理工具，使用其独有的声明式语言来描述基础设施状态。Puppet 的语言旨在高效处理 IT 基础设施的每个生命周期阶段，包括在数据中心和云基础设施中进行操作系统和应用程序组件的配置、补丁管理、配置管理和管理任务。

Puppet 专门设计用于处理类 Unix 和 Microsoft Windows 系统的配置。为此，用户使用 Puppet 的声明式语言或 Ruby 特定领域语言（DSL）分配系统资源及其状态。这样，基础设施配置将存储在称为 Puppet manifests 的配置文件中。当执行时，Puppet 工具会将 Puppet manifests 编译成一个系统特定的目录，其中包括资源及其依赖关系。然后，该目录可以应用于目标系统，Puppet 的操作结果将反馈给用户。

Puppet 通常采用客户端-服务器架构。在这种情况下，客户端称为代理（Agent），而服务器通常称为主服务器（Master）。此外，它还可以作为一个独立应用程序，从命令行执行，非常方便用于测试和基本配置。Puppet 服务器通常安装在多台服务器上，而 Puppet 代理则安装在所有需要管理的机器上。通过这种方式，Puppet 代理与服务器通信以获取配置指令并进行部署。代理接着在目标系统上实施配置，并立即将全面的状态报告发送到服务器。值得注意的是，机器可以作为守护进程运行 Puppet 代理，守护进程可以安排为定期作为 Cron 作业运行，也可以根据需要手动执行。

为了展示 Puppet 的工作原理，我们来看一个可以在 AWS 中创建 EC2 实例的 Puppet manifest 示例：

基础设施即代码（IaC）与配置即代码（CaC）有什么区别？

尽管 IaC 和 CaC 之间存在相似之处，但它们也有显著的区别。正如前文所述，IaC 主要用于部署虚拟基础设施，包括服务器实例、存储设备和网络组件，以及所需的任何额外资源和权限。相反，配置即代码（CaC）工具则在此基础上进行操作，生成基础设施后，CaC 工具负责配置和自定义操作系统、应用程序配置和监控设备。此活动用于自动化地创建计算系统，以精确满足客户或企业的特定需求和目标。这两种自动化工具各有其独特的优势，使它们适用于特定的使用场景，或者在一起使用时相辅相成。

为了帮助你理解它们的区别，可以用一个比喻来说明：基础设施即代码就像使用工具来建造一座办公大楼，而配置即代码则是一套用于为办公大楼配置设备和资源的工具，以便企业能够真正开展工作。

特别值得注意的是，在集成基于云的部署时，软件开发人员可以轻松且经济地创建多个测试环境并进行迭代。历史上，在本地环境中工作时，动态创建测试环境要困难得多，但现在这种情况已经改变。巧妙的是，计算机硬件制造商如 HP、Dell 和 SuperMicro 对其产品设计进行了许多改进，使本地体验更加现代化。如今，大多数机架式服务器的固件中都嵌入了 API，与市场上常用的 IaC 和 CaC 工具进行本地集成。这使得本地硬件具有与其云端竞争对手类似的功能，使它们在竞争激烈的市场中保持相关性。

持续交付流水线

合法的 CD（持续交付）流水线的主要特征是它能够在软件生命周期的任何阶段促进软件部署。换句话说，精心设计的 CI/CD 流水线基础设施应确保任何应用程序版本都可以轻松部署到指定的测试、预生产或生产环境中，仅需几次点击，并且具有绝对的幂等性。此外，开发团队应能够及时获得在任何环境中进行的自动化测试反馈，并利用这些反馈促进产品改进和提高运营效率。

持续交付流水线主要包括五个阶段：

图示说明了持续交付策略中的五个最常见阶段：提交（commit）、测试（test）、构建（build）、阶段（stage）和部署（deploy）。正如你所见，这个循环被设计得非常短，旨在促进从新代码更改提交到版本控制系统，到在生产环境中部署所需时间的最短化。除此之外，还包括几个验证步骤，以确保尽可能高的质量。这其中包括构建代码的能力，这本身就可以被视为一种测试形式。

值得注意的是，在产品为中心的公司中实现持续部署工作流程要比在以服务为中心的公司中容易得多。原因在于服务公司必须根据每个客户的需求量身定制解决方案，而产品公司则专注于更窄范围的价值流。

持续交付与持续部署的区别

在 DevOps 发布管理的背景下，持续交付和持续部署这两个术语表示了两种层次的自动化。

在持续交付中，手动部署新代码的需求减少了，节省了时间和资源。首先，代码被编写，然后自动化测试，接着获得批准，最后推送到一个代码库，其他工程师可以访问它。当代码完成后，运维团队可以快速获取它，并使用类似自助服务的功能将其轻松部署到实时应用环境中。

下图描述了持续交付和持续部署流程之间的区别：

正如你所见，这两者之间有一个显著的区别：生产环境的部署。在持续交付中，有一个手动批准步骤，在允许新代码更改部署到生产环境之前执行。而在持续部署中，自动化测试承担了这一职责，因此不需要任何人工干预。

通过将持续交付的自动化扩展到软件开发生命周期（SDLC）的下一阶段，持续部署可以帮助减少运维团队的工作负担，并加快应用程序的交付。任何辅助软件发布程序通常也会自动化，从而减少或消除人工干预的范围。例如，持续部署流水线可以设置为在新版本提交到 Git 代码库并部署到生产环境后立即进行部署，以便客户尽早使用。

持续部署比持续交付更难实施，因为它消除了在将授权软件产品部署到生产环境的过程中任何形式的人工干预。这意味着要实现真正的持续部署，自动化测试方案必须非常全面、互操作且可扩展。

GitOps 如何融入持续交付

GitOps 和 DevOps 之间存在一些显著的区别。或许最重要的一点是，GitOps 更加注重使用自动化和工具来有效管理和分发代码修改。相反，DevOps 更加注重促进团队成员之间的有效沟通与协作。另一个区别是，GitOps 广泛应用于容器化技术（如 Kubernetes），而 DevOps 则可以应用于各种其他类型的应用部署。

重要的是要认识到，GitOps 是 DevOps 更广泛领域中的一个专门领域，主要围绕使用 Git 代码库来有效管理基础设施状态和应用部署。GitOps 和 DevOps 之间的一个重要区别在于，在 GitOps 中，Git 代码库作为应用程序和基础设施部署状态的唯一权威来源。通过这种方式，Git 代码库充当了一个分类账，或类似于区块链的概念。

另一个需要理解的关键点是，GitOps 主要依赖于基于拉取的部署方法。使用传统的 DevOps 方法，持续集成和持续交付流水线由外部事件触发，例如将新代码推送到应用程序代码库时。而在 GitOps 中，基于拉取的策略通过主动比较当前部署的应用状态与版本控制代码库中声明的理想应用部署状态来保持应用的最新状态。如果两者之间检测到任何不一致，GitOps 操作员会更新实时基础设施以匹配指定代码库中声明的配置。

巧妙的是，基于拉取的部署使得在出现问题时，能够轻松将不稳定的软件部署回滚到最后已知的稳定版本。此外，基于拉取的技术是声明式的，使得高级部署策略（如蓝/绿部署和金丝雀部署）变得易于实现。

蓝/绿部署

蓝/绿部署创建了两个相同的环境。一个环境（蓝色）运行现有的程序版本，另一个环境（绿色）运行新版本。在绿色环境中的测试通过后，实时应用流量将定向到该环境，蓝色环境则被弃用。通过简化部署失败时的回滚，蓝/绿部署策略提高了应用的可用性并降低了部署风险。

由于 GitOps 部署是不可变的，因此可以轻松重置对实时基础设施的任何任意或未记录的修改。它在 Git 日志中强制执行所有更改的完整审计跟踪，并有助于避免可能导致系统状态不一致的直接集群更改。

金丝雀部署

金丝雀部署是一种渐进且受控的应用发布策略，在此策略中，流量在现有版本和新版本之间分配。该方法首先将新版本引入给一部分用户，然后再扩展其部署范围到整个用户群。通过遵循这种方法，可以在广泛分发给消费者之前确定应用更新版本的可靠性。

什么是持续测试？

到现在为止，你应该已经充分理解了自动化测试的重要性，至少从多次提到这一主题的次数上可以看出。自动化测试对于 DevOps 发布管理的重要性再怎么强调都不为过。

持续测试是在 CI/CD 的更广泛背景下的一种实践，它贯穿整个开发生命周期，有助于提升软件质量。通过精心策划的自动化测试策略，持续测试确保软件开发团队能够实时获取反馈，使他们能够尽快消除尽可能多的潜在风险和缺陷，覆盖整个软件开发生命周期。此外，团队成员将能够不断获得有关其产品的新见解，并找到改进的方法。

然而，在组织中实施持续测试并不是一个简单的过程，因为你必须制定一个测试策略，确保在不触发任何误报的情况下推动变更。就像持续部署一样，实施持续测试比听起来要困难得多，因为它们是相辅相成的。传统上，软件测试是在代码编写完成后首次进行的，然后转交给质量保证团队进行独立测试。当代码中发现错误时，代码会被交还给开发人员进行修正。这种测试模式在开发周期较慢的时代有一定的合理性。然而，它在当今环境下既具有挑战性又繁琐，并且容易引发潜在的中断和人为错误。相反，当代组织需要迅速交付高质量的产品，因为这是当今竞争激烈的数字市场中客户期望的。如果有资源能够正确实施，那么在以 DevOps 为中心的组织中，持续测试是最好的测试方式。

持续测试的价值就在于持续进行测试。如果代码在被添加到代码库后立即进行测试，可以在继续更多工作之前发现并修复错误。这样一来，就不需要未来的代码修改来修复错误，因为一开始就避免了它们的存在。在当今时代，开发人员甚至可以从自动化测试插件中受益，这些插件直接安装在开发人员的本地集成开发环境（IDE）中，例如 Eclipse、Microsoft Visual Studio 和 PyCharm。这使得开发人员有机会在编写代码时发现和修复问题，并在代码提交到源代码管理之前进行处理。

面向客户的软件质量保证需要通过端到端的全面测试来验证整个系统的运行情况，这有助于验证应用程序的性能是否符合预期。端到端测试要求使用真实数据和环境，以获得最可靠的结果。当使用代表真实生产数据的模拟数据时，你将能够更好地发现和修复代码中的问题。利用这些信息，你可以通过在真实世界的测试条件下模拟应用程序的运行情况，进一步了解应用程序在真实世界中的性能。顺便提一句，这一理念也是实施金丝雀部署的核心，金丝雀部署在生产中向一小部分用户暴露经过验证的预发布版本。

有效的持续测试需要依赖持续集成和持续交付。测试过程中的许多步骤，如代码构建、部署和分析，都可以借助 CI/CD 工具进行自动化。当使用 CI/CD 和 DevOps 发布管理时，可以更快地发布新功能和错误修复，同时仍能保持高质量标准。关注测试结果和用户反馈，确保你的软件持续改进。这些数据将帮助你发现流程中的问题，并做出必要的调整以改进它们。要保持高质量的软件，就必须保持对测试结果的高度关注。

在接下来的部分中，我们将探讨金融机构 Capital One 在进行自身的 DevOps 转型时如何充分利用 CI/CD 的案例研究。

Capital One 的 DevOps 转型

2010 年，Capital One 认识到其客户对在线和移动银行服务的偏好。鉴于此，执行领导层决定增强公司的技术能力，并建立一种文化，吸引并培养具有协作开发天赋的高技能技术人员队伍。Capital One 明智地优先招聘这些充满活力的人才，并确保他们与彻底理解业务需求的相关决策者密切合作。不久之后，该公司采用了敏捷软件开发技术，这些技术最终成为公司实施 DevOps 发布管理的基础。

及时响应客户反馈一直是 Capital One 的首要关注点。因此，DevOps 成为开发团队实现加速开发和部署周期的合理选择。在 2012 年至 2020 年间，Capital One 经历了一系列转型：

• 采用敏捷实践
• 创建自动化测试用例
• 使用 CI/CD 自动化部署和测试
• 将业务迁移到公共云提供商

通过这些调整，银行转型为一个拥抱开源解决方案和快速交付周期的组织。2020 年，Capital One 创造了历史，成为首家将所有传统本地数据中心迁移到公共云提供商的美国银行。

Capital One 的 DevOps 转型策略

尽管一开始只有少数员工参与，Capital One 还是致力于建立一个覆盖全公司的 DevOps 方法。随着时间的推移，公司实施了一个分三阶段的 DevOps 计划。

创建跨职能团队

Capital One 开始实施 DevOps 时，将专门和多才多艺的 SWAT 团队分配给公司内部的两个较老的应用程序。这些跨职能团队大力推行了配置管理和关键功能的自动化，并优化了这两个应用程序的工作流程。随后，每个团队继续主导其指定应用程序的交付过程。这一策略在 Capital One 的另外四个应用程序中得到了重复应用，之后管理层鼓励公司其他开发团队实施这些新发现的最佳实践。

值得注意的是，在 Capital One 的 DevOps 旅程初期，跨职能团队的存在和卓越的领导力极大地增强了公司建立共同目标的能力。对于开发人员和运维团队来说，掌握必要的 DevOps 技能以影响他人并在整个组织中传播这种文化也是非常有益的。

利用微服务架构

与其他在 dot com 时代存在的企业一样，Capital One 在设计其技术堆栈时采用了单体架构。随着时间的推移，项目开始扩展，使得必须考虑未来的需求。因此，银行投入了额外的资源，深入研究微服务架构及其在组织中的适用性。

在 Capital One，主要目标是提高交付速度，同时保持高质量标准。开发团队选择使用符合既定质量标准的自动化部署。他们为软件部署和生产中的修改制定了严格明确的规则。

Capital One 的团队在其流水线交付中实施了不可变的阶段：

• 实施有效的源代码管理
• 实施安全的应用程序和二进制数据存储
• 实施强大的特权访问管理和授权
• 确保定期进行质量和安全检查

每个应用程序团队都必须在将代码发布到生产环境之前满足这些要求。最终，Capital One 通过实施微服务架构获得了以下好处：

• 非对称服务部署
• 无限可扩展的应用程序
• 高可用性
• 职责和责任的逻辑分离
• 改进的错误处理

在 AWS 上构建按需基础设施

在收到客户反馈后，Capital One 的产品经理将精力集中在提升银行和金融服务的质量上，以提供卓越的客户体验。正是因为这个原因，组织采用了云优先策略，其架构师将新开发的应用程序迁移到了云端。

Capital One 的开发团队得益于以下 Amazon Web Services 工具，能够更快地获得有价值的用户见解并更快速地做出响应：

• 虚拟私有云 (VPC)
• 简单存储服务 (S3)
• 弹性计算云 (EC2)
• 关系型数据库服务 (RDS)

使用 Jenkins 自动化交付流水线

Capital One 采用了一系列流水线来全面扫描和测试代码，以确保整个公司保持高质量标准。此外，还进行类似的程序以确保加速交付。代码更新经过全面的自动化测试流程，包括集成测试、单元测试、安全扫描和质量检查。代码通过所有测试后，流水线会自动进行部署。通过确保服务不间断，用户可以享受无缝的体验，而团队可以轻松部署更新。

开发团队使用了 Jenkins 这一广泛使用的工具来创建持续集成和交付流水线。通过这种方法，Capital One 避免了从头开始创建自己的集成流程的需求。基于 Jenkins 的流水线有效地将整个开发过程分解为多个阶段，并进一步细分为其他步骤，如应用程序构建、集成测试和部署。值得注意的是，Capital One 采用了用于加速 Jenkinsfile 创建的样板工具，以加速各种应用程序的开发。

Jenkins 使 Capital One 简化了软件交付，增强了操作稳定性，并为开发人员整体上提供了更好的体验。

Capital One CI/CD 流水线中的治理

Capital One 致力于建立一种无畏的发布文化，以促进创造性思维。然而，这也要求采取一种心态，即个人对其决策和在软件交付中的角色负责。著名的策略家和 DevOps 宣导者 Tapabrata “Topo” Pal 和他的团队在 Capital One 实施了 "Clean Room" 开发的概念。他们调整了软件开发生命周期的概念，以接纳一种勇气和责任的文化。

CLEAN ROOM

"Clean Room" 一词指的是一个经过工程设计的空间，能够保持非常低的空气颗粒物浓度。它具有活跃的清洁能力、良好的隔离性和出色的污染控制。这类房间通常用于所有纳米级工艺的工业生产，包括半导体制造以及科学研究。为了保护其中处理的材料，必须将灰尘和其他空气中的生物（如气化颗粒）排除在洁净室之外。

公司虚拟开发洁净室的概念可以理解为一套确保代码在发布前达到质量的明确指南。这些政策涵盖了诸如定位和注册每个产品流水线、审核和检查每个版本的代码、限制对生产服务器的访问等程序。简而言之，洁净室方法强调的是防止缺陷，而不是消除它们。最终，Capital One 通过洁净室模型来检测和解决不同产品流水线中的问题，从一开始就保证质量。毕竟，预防胜于治疗。

下图全面描述了 Capital One 的 "Clean Room" DevOps 发布管理方法。该过程从开发阶段开始，应用程序代码被保存在版本控制管理中。然后，实施一系列安全措施，如限制对二进制文件的访问和包括静态代码分析。这部分的重点是确保所编写的代码在完整性、保密性和可用性方面得到妥善存储。

在洁净室流程的进一步阶段是测试阶段。此步骤确保质量保证程序的端到端可追溯性，从将功能测试活动与各自的用户故事关联开始。从那里，产品负责人与开发团队密切合作，确保所有关键测试都已执行并妥善记录。

洁净室流程的最后两个阶段包括实施和监控。在这些步骤中，生产过程需要达到最佳性能，包括测试部署脚本、批准变更、审核回滚程序、冻结源代码以及限制对自动化流程的访问控制。最后，版本被剪切并部署到生产环境中，并进行适当的应用监控。请查看整个过程的图解：

实施混沌工程

即使有多个访问控制和安全措施，软件部署有时也可能变得混乱。云故障往往难以预测且不可避免，它们可能在某些情况下（如可用性区域停电）带来风险。有人可能会认为，持续交付也带来了持续混乱的可能性。Capital One 拥有一个专门的团队，致力于解决这一特定问题。没有人愿意意外地自动化自己的毁灭。

传统方法难以预见由复杂的请求模式、不可预测的数据条件等引起的每一种可能的故障情境。2017 年，Capital One 受 Netflix 的启发，引入了自己形式的混沌工程。

公司实施了一种名为“Cloud Detour”的干扰工具，用来评估其构建的应用程序的弹性。在这一阶段，开发团队故意让关键任务应用程序遭受各种故障情境的考验。这有助于开发出能够保证足够弹性并作为强大灾难恢复练习的解决方案。

在 DevOps 工作流程中嵌入安全原则

起初，Capital One 遵循了一种劳动密集且耗时的安全认证流程。然而，公司很快意识到加强容器环境的重要性，以提高其在所有系统服务中的加密和整体安全态势。

因此，Capital One 将自动化安全检查集成到其 DevOps 流水线中。这加快了对容器和虚拟机镜像中配置错误和漏洞的评估。DevOps 团队快速获取了用于漏洞管理和策略合规性的 API 权限，这些工具可以被集成到 CI/CD 过程中。这使得他们能够进行必要的测试，获取报告，并启动纠正措施，而无需安全团队的参与。

我们能从 Capital One 的 DevOps 转型中学到什么？

正如你所见，通过研究 Capital One 如何实现其 DevOps 转型，我们可以获得许多宝贵的见解。在所做的诸多改进中，有一些尤为突出：

• DevOps 转型可能需要很长时间。在 Capital One 的案例中，他们从 2010 年开始，直到 2020 年才达到成熟状态。整整一个十年。要做好准备，在收获成果之前要承诺如此长的时间跨度。他们之所以称之为旅程是有原因的。
• 在满足用户不断变化的需求方面，速度至关重要。这正是你可以通过内部团队协作和流程自动化实现的。
• 采用 DevOps 实践并促进团队协作，可以激发创新文化和持续实验。采用快速失败的心态将帮助你迅速找到实用的解决方案。
• 实施持续监控实践可以帮助你的组织实现卓越的成果和可扩展性，即使你的流程最初进展缓慢。
• 集中化交付工具简化了每个团队技术堆栈的开发和管理，消除了各自为政的需求。最小化冗余工作并促进资源共享，最大限度地提高效率。
• 云基础设施允许灵活利用资源。因此，你可以轻松扩展并适应不断变化的需求而不受限制。
• 仔细审查所有当前的开发流程并建立质量标准以获得最佳结果。然后，简化质量控制流程以减少人为错误并促进 DevOps 合规性。

总结

本章总结到此为止。在我们的讨论中，你从发布经理的角度学习了 CI/CD 的基础知识。你现在掌握了持续集成如何激励开发人员不断将代码推送到源代码库，从而将他们的工作统一到一个单一的版本中。接着，我们回顾了为什么持续交付是持续集成的强大伙伴。然后，我们研究了持续交付流水线的所有适当阶段，以及它与持续部署流水线的区别。此外，你还熟悉了 GitOps，这是一种现代 DevOps 策略，通过引入基于拉取的部署策略来增强持续部署的概念。最后，我们探讨了持续测试，这是任何以 DevOps 为中心的软件组织的首选质量保证策略。

在下一章中，你将学习如何使用 GitHub Actions 构建一个包含简单 Web 应用程序的 Docker 镜像，并将其部署到 AWS EC2 上。