拥抱 DevOps 发布管理（一）

原文：annas-archive.org/md5/f4cc50968d1a83dfcdee3a4331510e52

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

为了简化构建和维护现代应用程序的复杂性，DevOps 工程师这一角色的需求迅速增长。这种思维方式专注于缩小 IT 运维和软件开发之间的瓶颈，其源自精益生产理念。

通过拥抱 DevOps 发布管理，软件开发团队受益于质量检查的整合和将测试、自动化以及质量保证流程提前到软件开发生命周期的做法。然而，发布管理仍然需要监控应用程序和基础设施组件，并管理变更请求和调度。

在本书中，你将了解发布管理的简短历史、什么是 DevOps 发布管理、它的独特之处以及实施它的基本策略。你将学习到 CI/CD 管道如何强制执行良好的 DevOps 发布管理，并了解如何优化这些管道。最后，你将学会如何创建一个跨职能的产品开发文化，从而减少浪费，增加客户价值。由于它在消除团队成员间孤岛方面的有效性，DevOps 发布管理正在成为目前最受欢迎的策略。

本书适用读者

本书面向 DevOps 工程师、软件工程师、项目经理、质量保证测试员和产品经理，他们负责软件产品的开发、质量保证、发布和部署。本书对于学习计算机科学或商业管理的教师、学生和研究人员也具有参考价值。

DevOps 和发布管理在软件开发、项目管理和 IT 运维方面有着紧密的联系。DevOps 发布管理涵盖了监督软件发布和交付周期中的设计、规划、调度、测试和实施等活动。

本书是为那些刚接触 DevOps 发布管理的读者提供的全面介绍。你将学习到将质量控制提前的关键技能，在创纪录的时间内构建高质量的产品。你将获得启动自己 DevOps 发布管理项目所需的知识，并且有信心推动公司的转型。

本书内容

第一章，理解软件开发生命周期，概述了软件开发生命周期（SDLC），这是软件行业创建新软件的程序。这种方法确保软件开发人员以最短的时间构建高质量、低成本的产品。

第二章，发布管理简要介绍，定义了什么是发布管理，它的文化意义以及技术视角。我们还将回顾发布管理的简短历史，了解它是如何随着时间的推移而发展的，包括对任何发布管理模型的标准六个阶段的回顾。

第三章，有哪些不同的 SDLC 发布管理模型？，介绍了发布管理模型，如 ITIL、瀑布模型、迭代模型、V 型模型、螺旋模型、激进式模型、敏捷模型以及 DevOps。

第四章，DevOps 发布管理试图解决哪些问题？，阐述了为什么 DevOps 的特性使其作为一种更优的发布管理方法论，强调了自动化、最小化风险、简化发布流程，并通过跟踪指标和分析关键绩效指标来衡量成功。

第五章，理解 DevOps 发布管理的独特性，讨论了发布管理作为一种整体实践，考虑了价值流中的每一个组成部分。DevOps 通过精心设计的自动化流水线和经过仔细选择的测试和审批过程，整合了 CI、CD、QA、安全性和反馈。

第六章，理解 CI/CD 的基础知识，探讨了 CI/CD，这是 DevOps 发布管理的关键策略。它自动化了传统上需要人工干预的大部分工作，从而实现新软件发布或将新代码推向生产环境。

第七章，技术发布经理的实用流水线，这一章将与本书的其他章节有所不同。你将学习如何构建一个包含简单 Web 应用程序的 Docker 镜像，并使用 GitHub Actions 将其部署到 AWS ECS。

第八章，CI/CD 流水线如何强化良好的 DevOps 发布管理，涵盖了包括管理市场推出速度和 CI/CD 治理、开发团队的分支策略、构建发布流水线以及实施适合 DevOps 发布管理的变更审批过程等主题！

第九章，在发布管理策略中拥抱 DevOps 文化，讨论了如何通过充分的规划和统一的方式发展 DevOps 文化。你将学习如何获得高层领导的支持，从零开始组建 DevOps 团队，并逐步定义促进协作和持续改进的流程。

第十章，领导层和利益相关者的支持是什么样子的，讨论了 DevOps 文化如何要求组织内领导层的坚定支持和积极参与。如果这些人不全心全意地支持并投入 DevOps 项目，这一项目很可能会失败。

第十一章*,* 克服 DevOps 发布管理中的常见陷阱，讨论了如何与组织的独特文化、工作风格和软件发布目标保持一致，以避免 DevOps 发布管理中的常见陷阱。如果您观察足够多的 DevOps 导向的公司，您会发现它们在运营过程中会遇到几个常见的陷阱。

附录，包含术语表、章节问题的答案、额外内容以及发布经理在日常工作中使用的常见文档模板。

如何充分利用本书

阅读本书内容需要具备一定的软件开发和产品开发基础知识。不过，拥有 DevOps 实践的基础知识将帮助读者更好地理解书中的练习。对于这些策略的新手，我们会提供相关参考资料。如果您有在敏捷或 DevOps 环境中工作的经验，将有助于您理解本书所涵盖的概念。

如果您正在使用本书的数字版本，建议您自己输入代码，或者通过 GitHub 仓库访问代码（链接将在下一节提供）。这样做可以帮助您避免与复制和粘贴代码相关的潜在错误。

下载示例代码文件

您可以从 GitHub 上下载本书的示例代码文件，链接：github.com/PacktPublishing/Embracing-DevOps-Release-Management。如果代码有更新，它将会在现有的 GitHub 仓库中更新。

我们还提供了其他代码包，来自我们丰富的书籍和视频目录，您可以在 github.com/PacktPublishing/ 中查看。快来看看吧！

使用的约定

本书中使用了多种文本约定。

文本中的代码：表示文本中的代码词、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 账号。例如：“从 GitHub 中，点击该仓库中的 task-definition.json 文件。”

代码块如下设置：

...    - name: Build, tag, and push image to Amazon ECR
      id: build-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}

粗体：表示新术语、重要词汇或屏幕上显示的词汇。例如，菜单或对话框中的词汇会像这样显示在文本中。例如：“展开 监控，然后开启 使用容器洞察 以启用容器洞察功能。”

提示或重要说明

如此显示。

联系我们

我们随时欢迎读者的反馈。

常规反馈：如果您对本书的任何部分有疑问，请通过电子邮件联系我们：customercare@packtpub.com，并在邮件主题中注明书名。

勘误表：尽管我们已尽最大努力确保内容的准确性，但错误总是难以避免。如果您在本书中发现任何错误，我们将非常感激您向我们报告。请访问www.packtpub.com/support/errata并填写表格。

盗版：如果您在互联网上发现任何形式的非法复制版本，我们将非常感激您提供相关网站或地址。请通过电子邮件联系我们：copyright@packt.com 并附上相关链接。

如果您有兴趣成为作者：如果您对某个主题有专业知识并有意写作或贡献一本书，请访问authors.packtpub.com。

分享您的想法

阅读完*《拥抱 DevOps 发布管理》*后，我们非常希望听到您的想法！请点击这里直接前往亚马逊书评页面并分享您的反馈。

您的反馈对我们以及技术社区非常重要，将帮助我们确保提供优质内容。

下载本书的免费 PDF 副本

感谢您购买本书！

您喜欢随时随地阅读，却无法携带纸质书籍吗？

您的电子书购买与您选择的设备不兼容吗？

不用担心，现在每本 Packt 书籍都会免费附赠该书的无 DRM 版 PDF。

任何地方、任何设备上阅读。搜索、复制并粘贴您最喜欢的技术书籍中的代码，直接应用到您的项目中。

特权不止于此，您还可以获得独家折扣、新闻简报，以及每天通过电子邮件收到精彩的免费内容

按照以下简单步骤获得福利：

1. 扫描二维码或访问以下链接

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_QR_Free_PDF.jpg

packt.link/free-ebook/978-1-83546-185-3

1. 提交您的购买证明

2. 就是这样！我们会直接将您的免费 PDF 和其他福利发送到您的邮箱

第一部分：理解软件开发生命周期及其设计

在本书的第一部分，我们将首先探讨软件开发生命周期（SDLC）以及它为何如此重要。接下来，我们将简要介绍发布管理和常见的发布管理生命周期阶段。然后，我们将深入探索各种 SDLC 发布管理模型的工作原理。尽管本书专注于 DevOps 发布管理，但首先理解 SDLC 及其与发布管理的关系，以及它们在整体项目管理中的位置，仍然至关重要。

本节包含以下章节：

• 第一章，理解软件开发生命周期

• 第二章，发布管理简要介绍

• 第三章，SDLC 发布管理模型有哪些？

第一章：理解软件开发生命周期

软件开发生命周期（SDLC）是软件行业用于创建新软件的程序。该方法确保软件开发人员能够在最短时间内构建高质量、具有竞争力的产品。

SDLC 涵盖了多个阶段，如规划、编写、测试和维护代码。软件工程师遵循软件开发生命周期来构思和开发适用于多个平台的软件应用，包括笔记本电脑、桌面计算机、云基础设施、移动设备、视频游戏系统、自助终端及其他技术平台。“生命周期”这一概念最早在 1950 年代被提出，用以描述创建新计算机系统的几个阶段。然而，它已经广泛应用于涵盖软件生产的所有阶段。

尽管本书关注的是DevOps 发布管理，但首先了解软件开发生命周期至关重要，了解它与发布管理的关系，以及两者在整体项目管理中的定位。简而言之，SDLC 是项目管理工具箱中的一项强大工具。它提高了团队每个人的关注度和效率，最大化了他们的生产力。

在第一章中，您将学习以下内容：

• SDLC 的定义

• SDLC 的七个阶段

• SDLC 与其他生命周期管理方法论的比较

定义 SDLC 并探讨其七个阶段

SDLC 指的是开发团队用来以最优成本效率生产高质量软件的系统化方法。其主要目标是降低风险，并确保所开发的软件超越客户的期望。通过这种方法，您将首先制定一个全面的战略，以指导产品开发，然后将其分解为更易管理的组件，便于安排、完成和衡量。

SDLC 可以理解为一个概念框架，概述了所选方法论所包含的多个阶段，而不是一种方法论本身。也就是说，SDLC 过程在不同的团队和产品中会有所不同。然而，值得注意的是，许多常见的 SDLC 模型在实际应用中共享相同的阶段。这些阶段包括规划与分析、设计、构建、测试、实施和维护/支持。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_01_1.jpg

图 1.1：SDLC 的七个阶段

1. 规划与分析

SDLC 的第一阶段是项目规划阶段，在此阶段，你将收集来自客户和利益相关者的业务需求。该阶段的主要目标是帮助你定义客户所面临的基本问题，并发现合适的解决方案。规划有助于识别开发新系统所需的关键组件，通过运用有计划和系统化的过程来满足项目需求。分析阶段使你能够在开始新的软件开发工作之前获得必要的资源。在此阶段，还需要计算完成项目所需的资源、成本和时间。

为了有效地确定生产范围、优先排序生产项目并制定开发节奏，业务分析师与客户合作，收集需求、确定目标群体，并与行业专家进行咨询。所有这些都是为了编写一份全面的业务规范(BS)文档。不同的组织和团队可能将此文档称为客户需求规范(*CRS)。需要注意的是，尽管创建 BS 文档被认为是良好实践，但一些开发团队可能选择不使用该文档，而采用不那么正式的方法，正如你将很快发现的那样。

BS 文档的目标是列出客户当前存在的问题，以便程序员能通过软件来修复这些问题。这可以作为一个有价值的工具，帮助团队跳出框架思考如何提升产品。确认软件项目符合业务和利益相关者目标、可行并满足用户需求后，应该将文档交给开发团队。

2. 定义需求

上述阶段至关重要，因为它有助于将你在规划和分析阶段所获得的数据转化为开发团队成员所需的明确定义的需求。定义需求有助于创建多个重要文档，包括软件需求规范(SRS)、用例文档和需求可追溯性矩阵文档，如果需要的话。

根据业务规范文档，开发团队的高级成员与利益相关者和专家合作，规划软件开发项目。该项目可能是开发一个新软件产品，或是提升现有产品的性能。在这个早期阶段识别潜在的困难至关重要。如果发现问题，管理者和开发人员会提出各种解决方案，然后进行展示和分析，以确定最佳的替代方案。

在开发的初步阶段，团队成员就以下内容进行合作，制定全面的计划：

• 项目的意图

• 项目的需求

• 预期问题

• 机会

• 风险

本阶段的主要目标是准确确定项目的功能需求。进行这一必要分析能够确保最终交付的成果与客户的具体需求和期望保持一致，并包含必须采取的积极措施，以确保满足客户的需求和偏好。

简而言之，这个 SDLC 阶段作为一个综合的技术蓝图，用于客户表达他们对项目的期望、需求和要求。通过定义这些元素，您可以确保在设计和开发过程中，软件项目的各个方面都能得到公平的考虑。

3. 设计

设计阶段是将想法转化为具体形式的时刻。初步的策略和愿景将在软件设计文档（SDD）中进一步发展和记录，该文档定义了多个方面，如系统架构、编程语言选择、模板使用、平台选择以及应用安全措施的实施。这也是您可以创建图表和流程图的位置，展示软件如何响应用户活动。有时，设计过程还包括创建最小可行产品或概念验证。产品的预生产版本有助于您想象最终产品的样子。这有助于确保所需调整尽量减少，也有助于团队避免完全重新编写代码。

SDD 在生产过程中将发挥至关重要的作用，尤其是在开发阶段（见第 4 阶段）。开发人员将主要依赖 SDD 作为编写代码的参考。为了减少在早期阶段识别到的潜在问题和风险，您还必须参考 SRS 文档。它作为设计产品的参考点，确保产品在设计时采取措施保护团队免受早期识别的潜在风险影响。

一个展示设计阶段有用性的现实世界例子是，地方和联邦政府机构如何利用这一阶段建立可扩展的框架，这些框架是一致且可重复的。为了实现这一点，SDLC 的设计阶段可能包含由集中管理的部门创建的预先安排的模板和指南，这些内容结构化，用于定义、实施和沟通项目的各个方面。例如，这有助于扩展用于颁发和管理驾驶执照、选民登记卡和图书馆卡的应用程序，这些卡在多个司法管辖区之间是互操作的。特别是在管理资源水平不同、领导风格各异的不同司法管辖区时，这一点非常有用，但它们必须保持联邦制。这种前瞻性思维有助于确定与实际实施相关的成本，或确保最终结果能够服务于所有相关的利益相关者。

在 SDLC 的第三阶段中，需要记住的一点是，最终用户应该有机会审查设计并提出任何对预期系统的修改意见。在这一阶段，你将与团队共同努力，创建最终的技术设计文档，然后进入生产阶段。此时，开发新软件或系统所需的所有必要要求应该已经确定，并且可以创建工作积压清单。

4. 开发

SDLC（软件开发生命周期）的第四阶段是项目真正开始的地方。在这一阶段，程序员、系统工程师和业务开发人员组成团队，开始进行软件开发。此时，通常会创建甘特图或看板，以确保项目工作的进展保持顺畅的节奏。开发团队通常会通过两种方法之一来组织他们的工作：实施冲刺或者作为一个持续的、连续的开发努力。无论采用哪种方法，团队都会尽力尽快完成任务。

重要说明

冲刺：冲刺是开发团队用来完成一定工作量的限定时间。冲刺的持续时间可以从一周到一个月不等，但通常是两周。冲刺的短时间限制促使开发人员优先发布适度的、渐进的改进，而不是发布大规模的变化。因此，程序的调试时间较少，最终用户的体验得到了改善。

持续开发：采用持续开发和敏捷开发的方式有许多相似之处。与其一次性对软件进行大规模的改进，不如通过持续的增量更新，将代码在完成并经过测试后尽早发布给用户。软件开发、测试和向生产环境发布更新都可以通过持续开发进行精简和自动化。

在开发阶段，产品代码按照 SDD（请参见第 3 阶段）编写，以确保产品可以高效地生产。这包括开发团队从零开始构建新系统，或以新的需求和新视角来处理现有项目。这可能包括从现有系统向云端的新系统进行平滑且具有成本效益的数字化转型。

在这个阶段，开发人员将项目拆解成更小的软件组件，这些组件最终将组成完成的产品。为了构建代码，开发人员会使用各种工具和计算机语言。这些工具和语言的选择是根据所构建软件产品的需求来决定的。

一些编程工具可能包括以下几种：

• 集成开发 环境 (IDEs)：

  • Eclipse

  • Microsoft Visual Studio

  • PyCharm

• 版本 控制系统：

  • Git

  • GitHub

  • Gitlab

  • Bitbucket

一些常见的编程语言可能包括以下几种：

• C#

• C++

• Python

• JavaScript

• Go

高层领导在这一阶段的紧密参与对于实现项目目标至关重要，因为 SDLC 的这一阶段可能需要大量时间。必须设定预定的时间框架和里程碑，以确保软件开发人员明确目标，并且你可以监控他们的进度。在这一阶段结束时，大部分的产品代码将完成。

在某些情况下，开发阶段可能与测试阶段重合，此时将进行特定的测试，以确保软件没有重大缺陷。

5. 测试

在不进行充分的测试其功能和特性之前，软件的生产既不可行也不明智；第五阶段专门用于测试。为了确保一切正常工作，质量保证工程师将进行一系列测试，包括代码分析、安全性、集成、性能和功能测试。通过反复测试和分析，可以成功解决缺陷和错误。在系统设计满足客户需求之前，你将需要进行持续的测试。尽管团队进行手动软件测试总比没有测试好，但最好在可能的情况下将所有测试都自动化。

产品测试应由质量保证团队在将软件发布到生产环境之前进行，以确保其功能完备并实现预期目标。在测试阶段，还可以解决用户体验或安全性方面的主要问题。无论如何，适当的测试将确保软件的每个组件都按预期工作。产品开发的最后一步包括验证、确认和用户接受测试。如果产品走到这一步，它很可能已经准备好发布。

包括测试在内，软件应经过正式的质量保证（QA）程序，以认证产品的质量。软件测试通常包括以下几种测试：

• 性能测试：性能测试是一种常用的测试策略，旨在评估系统在特定工作负载下的响应能力和稳定性。此外，它还可用于检查、量化、验证或证实多个其他系统质量特性，包括可扩展性、可靠性和资源利用率。

• 功能测试：功能测试，或称黑盒测试，是一种质量保证过程，通过基于被评估软件组件的文档需求来创建测试用例。功能软件测试的目的是确定系统或其各个部分是否满足预定义的功能需求。通过观察输入的响应来测试功能，通常不会考虑代码的底层结构。

• 安全测试：安全测试通过检测安全问题帮助信息系统保护数据并正常运行。由于安全测试的逻辑限制，测试通过并不意味着系统完美或符合安全标准。安全需求可能包括机密性、完整性、认证、可用性、授权和不可否认性。系统安全需求决定了需要测试的安全要求。安全测试有许多定义和方法，通过建立基础，安全分类法帮助我们掌握这些技术和含义。

• 单元测试：单元测试是一种通过评估离散代码部分或“源代码单元”来验证软件质量的技术，测试对象可以是一个或多个计算机程序模块，以及其对应的控制数据、使用过程和操作程序。

• UI/UX 测试：在用户界面（UI）测试中，测试人员验证屏幕上的元素，包括按钮、字段和标签，是否按预期执行。具有控件的屏幕，如工具栏、颜色、字体、大小、按钮和图标，作为 UI 测试的一部分，用于测试它们对用户输入的响应。UI 测试软件的目的是模拟最终用户与产品或服务的体验。

• 回归测试：回归测试是在进行修改后重新执行功能性和非功能性测试，以确认程序是否仍按预期工作。软件回归是指软件中的一个缺陷，某个以前正常工作的功能突然停止工作。软件更新、功能添加甚至微小的配置调整都可能需要额外的测试，以确保兼容性。由于随着每个缺陷的发现，测试套件呈指数增长，因此回归测试通常会采用自动化测试。

• 用户验收测试：软件开发的最后阶段是用户验收测试（UAT），在这一阶段，最终用户和客户会在实际场景中评估产品，以评估其功能性和实用性。UAT 重点考察软件是否能够在用户的实际系统中正常工作，而非其设计或功能。开发团队必须执行 UAT，因为他们的软件假设在日常工作中可能因为沟通不畅、误解、疏忽或需求变化而不成立。测试人员在实际情况下测试软件，并在 UAT 期间提供反馈，以便开发者在发布前修复任何缺陷。

6. 部署

在测试完成后，产品将发布到市场，但这可能仅仅是在你所在的组织内部。根据商业模式，产品部署可能涉及多个步骤，或者采用许多策略，从一次性发布到滚动发布或两者之间的某种方式。如果产品分阶段发布（如蓝绿部署或金丝雀部署），测试时间将会更多。最终产品的发布或对代码进行进一步调整的需求取决于收到的反馈。部署阶段通常会带来一些未知的、不理想的结果，你应该有所预期。

7. 维护

在第七个 SDLC 阶段，维护和升级被优先考虑。此时，系统可以进行调优以提高性能，并且可以随着时间的推移添加新功能。软件部署将会进行持续监控，以减轻潜在的性能和安全问题。此外，管理员或站点可靠性工程师一旦发现任何漏洞或缺陷，必须及时报告，以便尽快修复。

客户将根据自身的需求以不同的方式使用软件产品；这意味着可能存在需要修复的具体问题。这是因为用户可能会发现开发者和测试人员未注意到的缺陷和瑕疵。为了提升用户体验和提高用户留存率，立即解决和修复这些缺陷至关重要。在某些情况下，这些问题可能需要回到软件开发生命周期的第一阶段。软件开发生命周期的每个阶段，也可能因你在后续版本和升级中希望添加的新功能而重新启动。

一般认为，维护阶段是软件开发生命周期的最后阶段。尤其是在采用瀑布式发布管理的情况下，这一点尤其如此。尽管如此，业界正在向更敏捷的软件开发方法转变，例如 DevOps，其中维护仅仅是进一步增强的迭代步骤。

定义一些常用术语

以下是本书中常见的一些术语及其定义：

• 大爆炸式发布：大爆炸式发布方法缺乏其他发布管理模型中的过程导向特征，不需要提前准备。这一策略的主要焦点是软件开发，它允许程序员跳过规划阶段，直接进入代码生产阶段。

• 滚动发布：滚动发布，通常称为滚动更新，是一种软件开发模型。软件的改进是以持续、渐进的步骤进行，而不是通过离散的版本发布。用户可以随时升级程序以获取最新版本，并且被鼓励经常更新。

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

• 金丝雀部署：金丝雀部署是一种逐步且可控的应用发布策略，其中流量在现有版本和新版本之间分配。此方法首先将新版本引入一部分用户，随后再扩大到整个用户群体。通过这种方法，可以在新版本广泛发布之前，先评估更新版应用的可靠性。

在部署阶段结束时，您的最终产品将交付给终端用户。此时，部署工程师会在业务环境中安装软件和/或为用户提供帮助，确保程序能够正常运行。根据您的团队所遵循的 SRLC 类型，您可以自动化此过程并安排部署。例如，在实施单个功能更新的情况下，可以通过将其首先发布给有限的部分客户来执行此过程；这被称为“金丝雀发布”，如前所述。如果您正在开发全新的软件，您可能选择先以 alpha 版本在内部进行发布。稍后我们将简要扩展 SRLC，但该主题被视为超出本书讨论范围的内容。

现在我们已经涵盖了 SDLC 的七个阶段，接下来让我们看看它与其他生命周期管理方法相比如何。

SDLC 与其他生命周期管理方法的对比

如果您熟悉产品管理概念，那么您会知道，SDLC 并不是唯一的生命周期管理程序。以下是一些相关概念以及它们与 SDLC 的区别。

软件开发生命周期与系统开发生命周期的对比

系统开发生命周期是规划和构建信息技术系统的过程。有时，人们会用缩写 SDLC 来指代此过程；你看到了吗？这在指代软件开发生命周期时可能会造成混淆。在系统开发方面，一个系统通常由许多单独的硬件和软件组件组成，这些组件相互协作，执行复杂的任务和计算。只需知道，当你看到缩写 SDLC 时，要注意文献中的上下文线索，以便正确区分你所阅读的是指软件开发还是系统开发。

重要提示

在本书中，我们将把软件开发生命周期称为 SDLC。

SDLC 与系统开发生命周期之间有一些关键区别。SDLC 仅限于软件组件的创建和测试。相比之下，系统开发包括了硬件、软件、人员和流程的设置和管理，这些都是构成完整系统所需的。此外，SDLC 专注于程序本身，而系统开发可能涉及如组织培训和变更管理等活动，这些活动并不总是与软件开发相关联。

SDLC 与发布管理的对比

发布管理是指对 SDLC 的系统化监督和控制。其职责包括监督软件产品开发的各个阶段，即规划、设计、测试、部署和发布。发布管理的加入是 SDLC 的重要补充。发布管理的主要目标是确保开发团队有效地实现业务目标，并生产出高质量的软件。总的来说，发布管理在开发与运维领域之间起着至关重要的中介作用。

SDLC 与发布管理之间存在一些关键的区别。SDLC 的主要目标是降低风险，并确保开发工作有条理地进行。相比之下，发布管理的主要目标是确保开发团队的良好组织，并成功实现业务目标。此外，SDLC 主要集中在新软件的持续集成上，而发布管理则侧重于其持续交付。然而，两者都归发布或项目经理管辖。

SDLC 与 ALM（应用生命周期管理）对比

应用生命周期管理（ALM）是一个综合性的概念，涵盖了软件应用开发的整个过程，从初步的创意生成和设计阶段，到开发、测试、生产、支持，最终直至程序的退役。这个概念与 SDLC 相似，虽然在表面上它们可能看起来有相似之处，但需要注意的是，两者之间存在几个显著的区别。

SDLC 主要侧重于应用的开发阶段，而 ALM 则采取更为全面的方法，涵盖了整个程序的生命周期。有效管理应用开发的各个阶段需要多个 ALM 工具、流程和团队的协作与整合。需要注意的是，一个应用的生命周期可能在更广泛的 ALM 框架下，包含多个 SDLC。

SDLC 与 PDLC（产品开发生命周期）对比

产品开发生命周期是一个全面的过程，涵盖了产品的整个生命周期，从构思一个创意开始，到产品最终停产为止。这个过程包括产品规划、市场调研、产品设计、开发、测试、发布、营销和支持等活动。

SDLC 和 PDLC 之间存在一些关键的区别。SDLC 主要关注软件开发过程，而 PDLC 则主要集中于整个产品的开发。此外，SDLC 包括几个不同的阶段，包括规划、设计、编码、测试和部署。相比之下，PDLC 包含了附加的阶段，如市场调研、产品规划和产品营销。此外，SDLC 旨在开发符合最终用户特定需求的软件。而 PDLC 则专注于创建一个能够满足市场需求并为企业带来收入的产品。

SDLC 与 SRLC（软件发布生命周期）

收集、文档化和验证软件需求是软件发布生命周期（SRLC）的主要目标。收集来自各方的需求、按重要性排序、写入需求规格说明书，并检查其准确性，都是这一过程的一部分。

SDLC 和 SRLC 之间存在一些关键的区别。与 SDLC 相比，SRLC 更侧重于管理软件需求。SDLC 由规划、设计、编码、测试和部署等阶段组成，而 SRLC 则增加了需求引导、分析和验证等阶段。虽然 SDLC 力求创建满足用户需求的软件，但 SRLC 则在编码之前确保这些需求已经明确。

发布管理与变更管理

发布管理和变更管理是两个关键过程，在成功地将软件更新和增强功能交付给客户方面发挥着至关重要的作用。

发布管理和变更管理的领域是相互关联的，尽管它们的范围和目标不同。发布管理的主要目标是监督软件版本的全面交付，而变更管理则主要关注管理构成版本的各种变更。发布管理主要关注软件版本的技术方面，包括发布计划、环境和部署等元素。相反，变更管理则主要处理软件变更的业务方面，包括变更请求、审批和沟通。发布管理和变更管理涵盖了不同的角色和职责，包括发布经理、发布工程师、变更经理、变更分析师和变更审查员。

发布管理是指系统化地组织、协调、评估和实施跨多个环境的软件发布，包括开发、测试、预发布和生产环境。发布管理的主要目标是保证软件发布的及时交付，同时遵循预算限制并尽量减少终端用户可能遇到的任何潜在干扰。新特性、漏洞修复、功能增强和配置更改都是变更管理旨在跟踪的变更类型。变更管理的目的是使变更得到接受、文档化，并与相关方进行沟通，以便它们能对业务及其目标、需求和标准产生最大可能的积极影响。在部署任何修改之前，测试和验证软件系统的任何变更非常重要，这正是变更管理的核心内容。

发布管理与项目管理

发布管理一词用来描述监督软件发布的创建和分发过程，包括其规划、调度、测试和部署。它提高了开发团队交付的软件产品和升级的速度与质量。简而言之，发布管理是确保从开发到预发布，再到生产的顺利过渡的过程。从更广泛的角度来看，项目管理的目标是确保在预先设定的范围内完成特定项目的成功。这包括时间限制、计划、财务和沟通的规划。每当一个产品接收到新版本或更新时，这就算作项目的一部分。

项目管理和发布管理共同提高了团队成功完成项目的几率。发布管理与项目管理相似，都是具有明确结构和一系列阶段的过程，尽管方法本身是独特的。以下是一些项目管理方法的例子：

• Scrum

• 精益

• 六西格玛

• 极限编程（XP）

• PriSM

• PRINCE2

这就是第一章的内容。在这一章中，你了解了软件开发生命周期（SDLC）的定义，并探讨了它的七个阶段。最后，你了解了 SDLC 与其他生命周期管理方法的区别。在下一章中，我们将详细了解软件发布管理，以便理解其含义。

摘要

有了 SDLC 策略的帮助，项目管理变得更有效。管理者、设计师、开发人员和客户都能从这一工具提供的全面基础中受益。SDLC 的七个阶段都是至关重要的，并且相互依赖、相互促进。

在模型的初始阶段，资深成员负责收集需求。同时，IT 专业人员收集在产品生命周期内所需的所有数据和资源。在确定所需信息后，适当的文档将被草拟。随后的阶段包括设计和编码过程，接着是测试阶段，用于评估软件的功能性。最后阶段是部署和维护。团队可以选择使用不同的模型，包括广泛认可的瀑布模型和敏捷方法。对于软件开发来说，遵循 SDLC 至关重要。如前所述，了解 SDLC 的不同阶段是一种有效的方法，帮助产品经理在 SDLC 内部建立跨职能和以客户为中心的活动之间的共同理解和联系。这有助于在更广泛的企业目标、计划和努力中清晰地划分产品。

问题

1. SDLC 的定义是什么？

2. SDLC 的七个阶段是什么？

3. SDLC 和系统开发生命周期之间有什么区别？

4. 软件开发生命周期和发布管理之间有什么区别？

5. SDLC 和应用生命周期管理之间有什么区别？

6. SDLC 和产品开发生命周期之间有什么区别？

7. 发布管理和变更管理之间有什么区别？

8. 发布管理和项目管理之间有什么区别？

9. 蓝绿部署和金丝雀部署之间有什么区别？

10. SDLC 的七个阶段是什么？

第二章：发布管理简介

在软件工程领域，新发布或改进的软件产品被称为发布。这包括与其开发相关的所有程序和工件。

发布是软件开发和工程过程的高潮，它代表了产品的一个迭代版本，既全面又完全功能化。在软件产品向公众发布之前，通常会经过 alpha 和 beta 测试阶段。发布通常用于描述软件的最终、完善版本，尽管它也可以用来描述 alpha 或 beta 版本的首次发布。您也可能会在讨论发布时遇到“启动”和“增量”这两个词。

大多数公司使用顺序号或字母来标记它们的发布版本。术语软件版本控制描述了这种命名约定。每个组织都会一致地应用自己的内部标准，但语义版本控制（semver）是业内广泛使用的标准，规定了这些唯一标识符如何从一次发布到下一次发布演变。

在本章中，我们将定义发布管理，并了解其文化意义和技术视角。此外，我们将回顾发布管理的简短历史，了解它如何随着时间的推移而演变。最后，您将学习任何发布管理模型的标准六个阶段。需要注意的是，瀑布模型是最初的发布管理标准，但使用瀑布模型并非强制性要求。发布管理与您选择的模型无关，并且可以适应许多类型的 SDLC 模型，我们将在第三章中进一步讨论这一点。

本章将覆盖以下主要内容：

• 什么是发布管理，它是如何演变的？

• 解剖发布管理生命周期

什么是发布管理，它是如何演变的？

发布管理是一整套活动，涉及战略规划、构思、调度、严格测试、无缝部署以及有效控制软件发布的过程。此实践的主要目标是通过软件开发团队快速交付关键的应用功能和改进，同时保持已建立的生产环境的完整性、机密性和可用性，从而满足客户需求。

在商业和 IT 的竞争环境中，缺乏质量或功能的产品发布是让竞争对手获得优势的最快方式。现代企业是动态的，各种变化以不同的速度完成。企业需要发布控制和自动化部署来协调所有这些变化，以确保最终产品提供客户所期望的卓越价值。成功的发布管理提高了发布的频率，并减少了质量问题发生的频率，从而使企业能够更快地提供软件，同时减少相关的风险，提高生产力、沟通和合作。

由于这些改进，团队现在能够在比以前更短的时间内持续生成高质量的软件，这使得组织能够更好地应对客户需求或运营环境的变化。标准化和简化开发和运营流程是发布管理的另一个好处。团队建立了可以审计的发布控制，从而形成一个可以提取所有发布内容的集中位置。通过制定标准化、书面的发布流程，组织的成熟度可以进一步提高。如果团队标准化并专注于产品，他们可以从过去的发布中学习，并将这些知识应用到未来的迭代中。

运营和开发人员之间的沟通改进得到了广泛欢迎，因为它减少了意外情况的发生。现在，跨职能团队不必再担心发布后，运营因错过截止日期而被迫修补和祈祷或应急处理，而是能够减少这些问题。这样，团队可以有更多的时间来自动化业务流程或修复开发和生产环境中集成配置的不兼容问题。

定义

让我们快速定义在本书中可能会遇到的一些关键术语：

• 修补和祈祷：在软件开发中，所谓的“修补和祈祷”策略指的是使用脆弱的解决方案，有时被称为“补丁”，来解决缺陷或漏洞，而并没有解决问题的更深层次根源。

  组织普遍采用这种技术来设定严格的截止日期、优先处理其他活动，或弥补资源不足；然而，这种策略可能导致长期的技术债务以及显著的安全隐患。

• 灭火：在计算机科学领域，灭火是指分配资源来解决突发问题。这个词语表示的是调试，而非功能集成。灭火可能涉及在软件开发的产品发布临近时，增加工程师来修复发现的代码问题。

  很多企业已经做好了应对突发状况的准备，但频繁的紧急情况往往表明计划不周、效率低下，以及浪费本可以用于其他地方的资源。全面的灾难恢复规划（DRP）可以预见并或许避免灾难，从而最大限度地减少应急响应。

• 抛到墙外：这是商业术语，指的是完成了项目的一部分后将其交给下一个小组。这句话通常是在两个小组之间沟通很少，或者在新部署前几乎没有时间进行技术简报时使用的。

简而言之，发布管理促进了 IT 公司内部各部门之间的协作。这使得产品分发过程得以进行更全面的改进。

现在，既然你已经理解了发布管理的含义，我们来扩展一下这个话题。在接下来的章节中，我们将回顾发布管理的历史，看看新的模型是如何随着时间的推移出现的，并且如何与当时的当代软件开发理念对接。稍后，我们将通过审视任何发布管理模型应该包括的六个标准阶段来结束本章。

发布管理的简史

软件工程的焦点从基于项目转向基于产品的转变，促使发布管理的重要性日益增加。从发布管理的初期，任务是在基于项目的开发框架内执行的。在这种方法中，软件开发人员将每次发布视为一个独立的项目，而不是一个产品。一旦软件开发完成，通常意味着开发人员在过程中的角色也结束，他们会解散。

随着时间的推移，软件开发的过程逐渐演变，变得更加类似于产品周期，在这个过程中，产品会经历支持、增强和多次重新发布，跨越较长的生命周期。在这个特定的结构中，开发的主要目标不是发布本身，而是发布作为支持和修订活动开始的分界点。由于这种复杂性，阶段协调变得比以往任何时候都更为重要。因此，现代发布管理借鉴了以业务为导向的产品管理理念，其中包括售后支持和增强。

从软件到发布管理的演变

当英国计算机科学家汤姆·基尔本在 1948 年创建第一段软件时，他使用了 8 个工作存储字和 17 个指令字，共计 25 个字。从那时起，软件开发过程已经取得了显著进展。

尽管同事们嘲笑他，1953 年，保罗·尼凯特提出了一个概念：计算机的程序可以与设备的物理组件分开存储。从那时起，这一思想彻底改变了人们对计算的认知：

当我第一次大声说出“软件”这个词时，周围的人都说：“哈？”从一开始，我就觉得这个词太不正式，不敢写出来，甚至说出来也常常让我觉得尴尬。然而，带着带有些许得意的恐惧，我确实在五十年代时偶尔在演讲、讲座和媒体采访中使用过“软件”这个词。

（保罗·尼凯特，《导言：软件时代》）。

在 20 世纪上半叶，当电子数值积分器和计算机（ENIAC）等发明加速了计算机的发展时，软件尚不复杂到需要像软件开发生命周期（SDLC）这样的框架。最初的软件实现中使用了简单的工具，如跳转语句和 if/then 表达式。随着开发模型的需求不断增加，最终导致了 SDLC 的出现，而 SDLC 又受到结构化编程思想的启发。

结构化编程是一种编程范式，通过采用结构化控制流组件，如选择（if/then/else）和重复（while 和 for），以及块结构和子程序，来提高计算机程序的清晰度、质量和效率。1950 年代末，ALGOL 58和ALGOL 60编程语言的出现标志着该领域的一个重要发展。值得注意的是，ALGOL 60 在 1960 年引入了对块结构的支持，进一步增强了其功能。

软件开发方法论，通常被称为SDM，直到 1960 年代才开始实践。系统开发生命周期（SDLC）可以看作是最早公开发布的发布管理方法论和框架，用于构建大型计算机和其他模拟信息系统，早于软件开发生命周期的提出。系统开发生命周期的主要目标是系统地、精细地推进信息系统的开发。这意味着严格且按顺序遵循生命周期的每个阶段，从最初的构思到最终在所采用的特定框架内交付系统。值得注意的是，通过将系统替换为软件，诞生了一种新的 SDLC 形式。它力求成为行业的最终标准，通过详细列出创建和维护软件系统的输入、输出和步骤。

瀑布模型这一术语是在其正式的 SDLC 规范被发明多年后才出现的（你可以在第三章的图 3.2中看到瀑布发布管理模型的六个阶段示意图）。首次描述在软件工程中使用瀑布模型各阶段的报告是由赫伯特·D·贝宁顿（Herbert D. Benington）于 1956 年 6 月 29 日举行的，尽管当时并未使用“瀑布”这一术语。最早的正式、详细的瀑布模型示意图可以追溯到温斯顿·W·罗伊斯（Winston W. Royce）于 1970 年发表的文章，但罗伊斯的文章中并没有使用“瀑布”这一名称。瀑布这一术语据称首次出现在托马斯·E·贝尔（Thomas E. Bell）和 T.A.塞耶（T.A. Thayer）于 1976 年发表的研究论文中。到 1985 年，瀑布发布管理方法被美国国防部在 DoD-STD-2167A 标准中正式规范。美国国防部针对与软件开发承包商合作的标准中指出：“承包商应实施一个包括以下六个阶段的软件开发周期：软件需求分析、初步设计、详细设计、编码与单元测试、集成和测试。”

从 1960 年代 NASA 的水星计划开始，迭代和增量开发（IID）成为瀑布发布管理的最早也是最接近的竞争者之一。部分水星计划团队成员后来成立了 IBM 的一个子公司，负责为航天飞机创建核心的航空电子软件系统，该系统从 1977 年运行到 1980 年。在 31 个月的时间里，该团队进行了 17 次 IID 迭代，每次迭代的持续时间平均为 8 周。他们决定放弃使用瀑布开发方法，因为航天飞机计划的需求在软件开发过程中已知会发生变化。

在 1986 年的研究中，巴里·博厄姆（Barry Boehm）首次概述了螺旋模型，并提供了如今广为人知的示意图，后续有许多出版物采用了这一图表进行讨论：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_02_1.jpg

图 2.1：螺旋发布管理模型（图片来源：static.hlt.bme.hu）

IT 基础设施库（ITIL）始于 1980 年代，响应数据中心的去中心化和地理多样化架构的使用。这种行为导致了流程和部署的差异，进而引发了企业内部 IT 服务管理的不一致或不满意。英国的中央计算机与电信机构（CCTA）认识到将信息技术视为一种服务，并在整个信息技术服务生命周期内使用一致的程序的重要性。因此，CCTA 制定了政府信息技术基础设施管理方法论。到 1989 年，CCTA 发布了 ITIL 版本 1。

V 模型概念在 1980 年代后期同时出现在德国和美国，尽管是独立发展的。美国的 V 模型在 1991 年《国家系统工程委员会》（NCOSE，自 1995 年起更名为 INCOSE）的会议记录中进行了阐述，专门为涵盖硬件、软件和人机交互的卫星系统设计。德国的 V 模型最初由 IABG（位于奥托布伦的研究与开发机构）制定，并与位于科布伦茨的联邦国防技术与采购局合作。这项联合工作由联邦国防部主导。1992 年夏，联邦内政部接管了民用公共权威领域的管理。

Jacobson、Booch 和 Rumbaugh（1999）在其名为《统一软件开发过程》的著作中提出了统一过程的概念。这部开创性的著作首次提出了一个敏捷框架的软件开发方法论。

敏捷发布模型的起源发生在 2001 年，美国犹他州 Snowbird 的一家著名度假村。17 位著名软件工程师聚集一堂，讨论轻量级开发方法论，最终共同制定了敏捷软件开发宣言（即“敏捷宣言”）。2009 年，与敏捷宣言共同作者之一罗伯特·C·马丁（Robert C. Martin）相关的一群人，发展出了一个软件开发原则的扩展，称为软件工艺宣言。该宣言旨在根据职业道德和精通的原则，引导敏捷软件开发的实践。

2007 年，一位名叫 Patrick Debois 的 IT 顾问在意识到开发（Dev）和运维（Ops）团队之间的合作效率不高后，提出了 DevOps 方法论。尽管他一直觉得 Dev 和 Ops 之间的分歧和矛盾令人不悦，但在一个他负责测试的大型数据中心迁移项目中，团队间的不断切换和反复工作令他尤为沮丧。有一天，他完全沉浸在敏捷软件开发的流程中。第二天，他又参与了紧急问题处理，亲身体验了传统运维带来的不确定性。他确信一定有一种更高效的方法。

Andrew Shafer 在 2008 年敏捷大会上组织了一次志同道合者（BoF）聚会，讨论敏捷基础设施。Andrew 原以为没有人会参加这次会议，所以他决定自己不去参加。当 Patrick Debois 出现时，他立刻去找 Andrew，讨论将敏捷基础设施作为让运维像开发人员一样敏捷的解决方案。这就是 DevOps 运动的起点。

在 2009 年的 Velocity 大会上，John Allspaw 和 Paul Hammond 做了一个题为“每天部署 10 次以上 - Flickr 上的开发与运维合作”的演讲，之后这个概念开始在开发团队中获得普及。此次讨论让人们看到了通过采用这些早期的 DevOps 方法，可能实现的各种可能性。此外，Patrick 还组织并主持了 2009 年 10 月在比利时根特举行的第一次 DevOpsDays 大会。此次大会被称为将开发与运维结合的大会，也是DevOps一词首次公开亮相的地方。如今，DevOpsDays 大会已经成为一个在多个地区定期举办的国际性活动。

在下图中，您将看到发布管理历史的时间线。从 1953 年“软件”一词首次提出开始，您可以看到从瀑布模型到 DevOps 的演变。讽刺的是，或许也不那么讽刺，您将发现这两种模型一直被使用，直到今天。一个值得注意的地方是，随着时间的推移，进展的速度是如何加快的，从几十年到仅仅几年。了解过去的历程对于理解现在的成就至关重要。发布管理的历史最终促成了 DevOps 的诞生。了解这一点对于理解为什么 DevOps 已成为软件开发历史上最广泛采用的发布管理模型之一非常重要：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_02_2.jpg

图 2.2：发布管理历史时间线

到目前为止，你已经了解了发布管理的目的及其历史。现在，你知道了新模型是如何随着时间的推移而出现的，以及它们为什么反映了当时的哲学思想。接下来，让我们通过研究发布管理模型应该包括的六个标准阶段来总结本章内容。

解剖发布管理生命周期

发布管理生命周期包括多个不同的阶段：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_02_3.jpg

图 2.3：发布管理的六个标准阶段

这一过程的变动性取决于所选择的发布管理模型、产品设计、团队和组织，因为它们都受到特定项目需求的影响。尽管如此，组织和团队无论规模大小，都必须遵循一套普遍适用的程序，以实现财务可持续性并为用户提供高质量的成果。

现在，让我们看看发布管理的标准程序包括哪些内容。

请求

对新功能请求或现有功能修改的请求是发布管理过程中的第一步。不能保证所有的请求都会导致新的发布。每个请求都需要经过分析，以确定它是否合理，是否可以实施，以及当前版本的应用是否可以修改以适应该请求。

无论你是从零开始，还是想要改善已经建立的产品，了解对你的期望是至关重要的。不要假设你已经知道客户希望在应用程序或相关产品中包含哪些功能和特性。举个例子，客户可能要求你将一项新功能集成到他们的移动应用中。你需要与他们坐下来开会，全面了解他们的需求、愿望和动机。

无论你的目标是什么，确保在进行计划和开发之前充分理解它。如果你有任何疑虑，在继续之前与你的团队或客户进行咨询，以制定出符合需求的合适发布策略。

计划

在你完全理解发布需求后，下一步是计划。为了构建和发布你打算做的内容，你需要进行全面的规划和准备，这些准备工作应基于所有相关方的需求。在技术、截止日期、人员和资源方面，你的准备需要合理且务实。例如，如果你正在开发一个应用程序的新版本进行发布，你需要在各种平台和设备上进行充分的测试，然后才能发布给客户。

如果你与客户保持定期联系，规划就会变得更加容易。项目的进度和最终交付日期可以进行讨论。你不能承诺一个不可能完成的截止日期。在确认截止日期时，要考虑到可用资源（资金、时间和人员）。此外，在发布之前，考虑你将使用哪些技术并进行相应规划是明智的。考虑你的选择是否具备成本效益，是否符合预算，并且是否能充分利用团队成员的才能。选择那些能够帮助你快速且轻松地设计高质量产品并将其推向客户的工具。规划还需要高效地分配和利用现有资源，以防止浪费，并确保产品的高效构建。

你可以选择多种方式来概述你的计划，其中之一是使用发布管理检查清单。在检查清单中，应按大致的时间顺序概述各个角色和责任。如果你的团队查看该清单，他们应该能够轻松地确定当前所处的阶段，以及他们在过程中的任务或角色。为了制定一个稳固的发布计划，与你的开发团队和运营团队召开会议，讨论需求、障碍和克服障碍的策略，包括实现目标的最有效方法。如有疑问，邀请客户参与讨论。

设计与构建

在战略完成后，接下来的步骤是设计和开发产品。根据这些具体需求制定的计划和策略现在可以付诸实践。为了完成这一阶段，程序员需要编写代码，这些代码最终将转化为你计划添加到产品中的特性或功能。

在整个发布周期中，这一阶段可能会反复进行，类似于 DevOps 中的持续开发策略。在开发者完成编写代码后，代码中可能存在许多问题、故障和缺陷，需要进行测试。在最终接受之前，代码将经历多轮测试。所有需要解决和优化的问题列表应该提供给开发者，以便他们能够优先处理待办事项，并生成符合预期的高效软件。帮助解决这一问题的一个方法是使用缺陷跟踪工具，如FindBugs、Eslint和Sonarlint。

测试

如前所述，测试代码是保证没有错误或缺陷的必要步骤，这些错误或缺陷可能会影响软件的功能、速度或安全性。手动测试总比没有测试要好，但在可能的情况下，应实施自动化测试。

功能测试和非功能测试这两个术语有时被误用为可以互换的概念。如在第一章中提到的，实际上可以进行多种类型的测试，通常都归属于这两个类别。当发现问题时，代码会被送回开发人员，以便他们修复问题并重新提交代码进行进一步审查。

用户验收测试是将软件产品发布给最终用户之前的最后一步，在此过程中，客户将验证软件是否符合他们的需求并按预期运行。接下来的步骤取决于用户的验收情况。否则，用户的反馈将用于修订代码，然后再进行进一步测试，最终发布。

部署

在软件开发团队确认产品已经按照规格开发并且没有错误后，他们将准备将其发布到公众或部署给客户。

此外，质量保证（QA）团队将负责执行最终测试，以确保成品符合所有产品发布计划的业务需求和最低标准。然后，管理层或产品负责人将检查该产品，确保它可以发布。

到这一阶段，已完成帮助其他开发人员理解软件并学习如何使用它所需的文档。此外，团队还完成了所有必要的文档，以便将完成的产品交给客户。除此之外，公司还应考虑为消费者或员工提供培训，教他们如何有效地使用新产品。

部署后

无论发布是为内部使用还是为客户开发的，与其相关的任务都超出了部署阶段。无论软件当前的效率和功能如何，定期维护仍然是必要的，以确保最佳性能。

此外，安全问题可能随时发生。一旦发生，这可能会对您的公司及其声誉产生毁灭性的影响。许多不同的因素可能会影响您的软件，导致性能问题、崩溃、安全漏洞、可用性问题等。因此，即使软件已提供给最终用户，您也不应停止监控。您需要抽出一些时间，调查系统的性能、安全性、可用性和稳定性，以便在问题对用户产生影响之前发现并修正它们。

从最初的构想到最终的部署和维护，这就是发布管理过程的样子。

总结

现在我们已经到达本章的结尾，让我们快速回顾一下本课的主要要点。你现在已经了解了发布管理的含义及其历史。

了解你在发布管理过程中所处的位置至关重要。你应该从定量和定性两个角度来审视这个问题。收集一些基本数据，例如平均发布时间、发布类型及优先级、错误数量和延迟发布的数量，是定量分析过程中的重要步骤。这些数据用于确定性能基准和发布管理的当前状态。在信息质量方面，与你的发布管理流程中相关的人员进行沟通，特别是在开发与运维交互的领域，了解他们的看法。他们能够指出数据和统计数字中未明确反映的实际情况。

建立常规的发布周期有助于创造一致性，使你能够掌控发布管理任务和职责。与其从一开始就专注于建立文化，不如先实施轻量级的发布流程。这样，你能够在早期阶段设置发布的基础设施，进行测试，并根据需要进行调整。随着时间的推移，最有效的流程最终会成为你组织的标准。在完成初步研究后，你将能更好地启动更严格的质量标准并提高效率。消除停机时间和回归测试是减少发布对用户影响的两种方式。到那时，你还可以开始考虑规范化和自动化流程，比如测试和验证，这两者都是开发过程中的关键步骤。

真正的协作文化在发布管理中需要时间来成熟，而且它需要一个良好管理的基础设施作为成熟的基础。你可以通过对团队的投资以及投资于发布管理工具和方法，来培养这种文化，使人们能够全面了解发布管理过程的每个阶段。这两种投资都将帮助你建立卓越的文化，并使工作更加可见。

这就是第二章的结束。在这一章中，我们从文化和技术两个角度学习了发布管理的定义。然后，我们简要回顾了发布管理的历史，以及不同模型如何随着时间的推移而诞生。最后，你看到了任何模型应该具备的六个标准发布管理阶段。

在第三章中，我们将深入探讨最常见的发布管理模型的机制。这里需要特别强调的是，如果你不了解 DevOps 之前的发布管理模型，那么几乎不可能完全理解 DevOps 的含义。

问题

回答以下问题，测试你对本章的理解：

1. 是软件开发生命周期先出现，还是系统开发生命周期先出现？

2. 系统开发生命周期和软件开发生命周期有什么区别？

3. “软件”这一术语首次是在何时由谁提出的？

4. 谁被认为是撰写第一个瀑布发布管理模型规范的人？

5. 谁被认为是“瀑布模型”这一术语的创始人，并且这个术语是在什么年份提出的？

6. 任何发布管理模型的六个标准阶段是什么？

7. 谁被认为是 DevOps 方法论的创始人？

8. 第一个 DevOpsDays 活动在哪一年举行，地点在哪里？

9. 结构化编程在哪一年普及并成为主流？

10. 迭代式和增量式软件开发在哪一年首次被使用？

第三章：各种 SDLC 发布管理模型是什么？

软件开发团队可以使用各种框架或发布管理模型来组织他们的工作。这些模型帮助组织实施软件开发生命周期（SDLC），通过不同的策略实现相同的结果。一个发布管理模型包含软件开发人员用来组织工作并交付软件产品或功能的各个阶段。一般而言，每个模型包含以下六个阶段：变更请求、规划、设计与构建、测试、部署和发布支持。

发布管理模型确保根据客户需求生产高质量的软件。为了实现这一目标，创建了各种发布管理方法论，如 ITIL、瀑布模型、迭代模型、V 模型、螺旋模型、大爆炸模型、敏捷和 DevOps，但有一些较不流行的模型不在本书的范围之内。我们来回顾一下最常用的 SDLC 发布管理模型：

• ITIL 模型

• 瀑布模型

• 迭代模型

• V 模型

• 螺旋模型

• 大爆炸模型

• 敏捷模型

• DevOps 模型

ITIL 模型

英国政府的中央计算机和电信机构（CCTA）创建了信息技术基础设施库（ITIL）模型：一套用于 IT 活动的最佳实践，如IT 服务管理（ITSM）和IT 资产管理（ITAM），其起源可以追溯到 1980 年代初期。这些实践的核心理念是将 IT 服务与公司运营的需求对齐。2000 年，CCTA 并入了英国的政府商业办公室（OGC）。

在初期，企业 IT 部门被高级领导视为成本中心，而不是它们所具备的价值增值者。当时，许多公司没有建立获取服务或报告 IT 事件的协议，IT 与业务的沟通也较差。因此，许多公司的领导认为 IT 没有创造价值或达成公司目标。随着企业 IT 部门的逐渐增多，他们意识到必须通过满足业务定义的可衡量结果来证明自身的价值。

随着 ITSM 范式的出现，企业的注意力从 IT部门转移到了 IT服务的管理和履行。ITSM 对于 IT 专业人士来说是新鲜的，他们被视为一个独立的实体，而业务单元则被视为他们的客户。为了服务客户，IT 提供由技术资源和专业知识支持的服务。因此，为了展示价值，IT 必须按照既定的服务水平协议提供这些服务，并满足战略业务需求。

ITIL 指导整个服务生命周期中的 IT 服务管理。其核心是一个框架，用于管理组织的 IT 基础设施，从而实现战略目标、创造商业价值并确保基本的能力标准。公司可以利用这一基准作为未来规划、实施和评估的起点。

正如你现在可能已经推测到的，ITIL 发布管理模型更多地与系统开发相关，而非软件开发。话虽如此，ITIL 被认为是企业环境中最早且最广泛实施的发布管理模型之一。尽管 ITIL 在软件发布管理中是一个特例，但要了解 ITIL 是什么，以及它如何融入整体发布管理生态系统。现在，让我们来看看 ITIL 的两个最新版本：V3 和 V4。

ITIL 3

OGC 在其 IT 服务管理（ITSM）战略上取得了重大进展，并提供了超越 ITIL 版本 2 的深度和全面性的更新指导。ITIL 版本 3 于 2007 年向公众发布，结构上是将服务生命周期划分为五个独立的阶段。这些阶段包括服务战略、服务设计、服务过渡、服务运营和持续的 服务改进。

每个阶段都旨在涵盖服务生命周期的特定阶段，可以总结如下：

• 服务战略：制定更好服务客户的计划。服务战略过程从分析客户需求和市场状况开始，建立 IT 组织要提供的服务以及要构建的能力。最终目标是将 IT 部门的思维方式转变为战略规划和执行的思维方式。

• 服务设计：开发新的信息技术（IT）服务。该过程的广度涵盖了新服务的创建以及现有服务的修改和增强。

• 服务过渡：创建和发布计算机系统。对服务和服务管理流程的变更以协调的方式实施，这是服务过渡职能的另一个职责。

• 服务运营：确保 IT 服务得以良好且迅速地提供。在服务运营过程中，满足用户需求、修复服务故障、解决问题以及完成日常操作任务。

• 持续服务改进：应用质量管理技术深入了解当前和过去的表现。持续服务改进过程的目的是将 ISO 20000 采纳的持续改进概念应用于 IT 过程和服务，以最大化其有效性和效率。

下图展示了 ITIL V3 发布管理模型的各个阶段：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_03_1.jpg

图 3.1：ITIL V3 发布管理模型

这就是我们对 ITIL V3 的介绍。我们同时观察 ITIL V3 和 ITIL V4，因为它们之间有一些显著的差异。值得注意的是，ITIL V4 是一个最近的更新版本，其过程图并没有保留 ITIL 早期版本所著名的传统。ITIL V4 的变化带来了更具灵活性的服务框架，而不再是一个僵化的 IT 服务管理模型。

ITIL 4

自 2007 年以来，ITIL 没有进行过重大修订；因此，ITIL 4 可能是对竞争性服务管理框架如 VeriSM™、SIAM® 和 FitSM 兴起的回应。它是 ITIL V3（也称为 ITIL 2011）的一个更新和扩展版本，能够作为企业进行数字化转型的灵活基础。

ITIL 版本 4 概述了为 IT 支持的产品和服务提供服务的过程框架。文档经过了大量修改，以使其更加易读，并且添加了多个示例。ITIL 4 还考虑了现代软件工程和信息技术管理实践，提供了使用敏捷（Agile）、开发运维（DevOps）和精益（Lean）等方法论在服务管理中的应用指导。最后，ITIL 4 强调它是 服务管理框架（而不是 IT 服务管理），这反映了服务管理最佳实践在 IT 行业之外的广泛应用。

需要记住的是，虽然 ITIL 确实是一种发布管理方法论，但它与系统开发生命周期的相似性超过了与软件开发生命周期的相似性。正因为如此，ITIL 排在我们的列表首位。现在，让我们将注意力转向瀑布式发布管理模型。瀑布式模型是最初用于组织专注于构建信息系统的项目的发布管理标准。瀑布式模型诞生于那个关键时期，当时工程师们正从用开关板和电缆编程计算机过渡到使用穿孔卡片上刻出的逻辑序列。这标志着历史上首次可以独立于物理机器编写和管理程序。

瀑布式模型

瀑布模型是一种将项目阶段按线性顺序组织的方法。这意味着每个阶段建立在前一个阶段的交付成果基础上，并对应于不同的任务专业化层次。这种方法在多个工程设计领域中得到了广泛应用。由于进展大多是单向的（向下，就像瀑布一样），这种方法通常被认为是软件开发中最不具备迭代性和适应性的模型之一。原因在于，团队只能在瀑布过程中向前推进，无法回退。这个不可变阶段的线性进展包括需求收集与分析、系统设计、实施、测试、部署和维护。

瀑布模型是第一个用于软件开发中的发布管理 SDLC。制造业和建筑业被认为是瀑布开发模型的发源地。在这些行业中，高度组织化的环境意味着在制造过程中，进行设计修改会变得极其昂贵。最初在软件开发中实施时，并没有公认的替代方案来进行基于知识的创意工作。

瀑布发布管理方法因其缺陷而遭遇了显著的反对。在客户看到功能软件之前，他们可能并不完全了解自己的需求，这可能导致他们在事后更改需求。这将导致需要重新设计、重新开发和重新测试，从而推高成本。软件工程师和业务开发人员可能缺乏对新软件产品或功能设计过程中可能出现的潜在挑战的预见。在这种情况下，最好重新评估设计，而不是继续执行一个未考虑到任何新发现的限制、前提条件或问题的设计。

每个阶段性的过程在查看其各个阶段及流程图后，能够更好地理解。观察瀑布发布管理模型的图示，确实能轻松理解它的不可变步骤的线性顺序是如何赋予瀑布模型这一名称的：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_03_2.jpg

图 3.2：瀑布发布管理模型的六个阶段

如你所见，瀑布发布管理模型非常适合组织一个庞大的工作，涉及数百甚至数千名开发人员在同一个项目中。现在你已经对瀑布发布管理模型有了基本的了解，你也能很好地理解后续更先进的发布管理模型的概念。

我们接下来将研究的发布管理模型是迭代增量模型，通常简称为迭代模型。该方法通过小步增量的方式，或称为迭代，来构建系统。这个发布管理模型是瀑布模型的最早和最直接的竞争者之一，起源于大约 1960 年。因此，我们将接着讨论迭代增量发布管理模型。

迭代模型

这一技术的概念是通过小步增量的方式，或称为迭代，构建系统，以便软件工程师能够从构建系统先前版本的经验中受益。在系统开发和使用过程中，学习不断发生，关键步骤可能从软件需求的子集的初步实现开始，通过迭代的方式逐步改进，直到整个系统实现。设计的修改和新功能会在每次迭代开发周期后融入系统，如下所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_03_3.jpg

图 3.3：迭代增量发布管理模型

该技术具体分为三个步骤：初始化阶段、迭代步骤和项目控制清单。系统的起始点在初始化过程中构建。在开发的第一阶段，我们希望提供给用户一些可以反馈的内容。它应该提供对问题的全面概述和直接的解决方案。在每次迭代开始时都会编制项目控制清单，以记录所有未完成的任务。它包括重新设计当前解决方案的部分内容或添加全新的功能等内容。分析步骤将导致控制清单的持续更新。

迭代的重新设计和实施应该易于理解和应用，无论是在迭代过程中还是作为一个单独的任务添加到项目的控制清单中。迭代方法并不要求设计具有特定的粒度。然而，在关键的迭代项目中，可能会使用正式的软件设计文档来补充代码，作为系统文档的主要来源。迭代的分析基于用户反馈和可用的程序分析工具。这包括对结构、模块化、可用性、可靠性、效率和目标达成情况的检查。项目控制清单会根据研究结果进行更新。

在迭代开发中，您的团队将对软件进行逐步改进和调整，直到其完全功能化。每次迭代应旨在提升整体产品，而不仅仅是产生一个新的功能或组件。迭代式管理风格允许根据需要对项目进行调整，以确保成功。这有助于开发团队考虑任何未预见的方向变化，无论是正面还是负面。

一位合格的迭代项目经理必须能够在项目进展过程中进行这些调整，同时尽量减少对团队的干扰，并关注其他团队成员的反馈，以确保项目的进度和预算可控。此外，问题和困难可以及早识别并修复，从而节省时间和金钱。当您定期提供可行的产品增量时，消费者可以更早地提交反馈，从而产生更符合用户需求的优秀软件。如果产品以迭代和增量的方式进行管理，就不会出现最后一分钟的调整或匆忙满足不切实际的截止日期。

这就是我们对迭代和增量发布管理模型的介绍。如您所见，迭代和增量模型与几十年后出现的敏捷发布管理模型非常相似，我们将在本章后续部分讨论它。现在，让我们换个角度，将重点转向 V 型发布管理模型。

V 模型

V 模型得名于它与字母V的相似性。这个 SDLC 发布管理模型在 V 模型中被分为多个阶段，每个阶段都有自己的专门测试阶段。V 模型的左侧代表验证阶段，而 V 模型的右侧代表确认阶段。V 模型是创建系统过程中各阶段的图示，它用于构建项目管理和开发生命周期的严格模型。下图展示了 V 模型：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_03_4.jpg

图 3.4：V 型发布管理模型

V 模型提供了计算机化系统验证框架中的主要活动及其相关输出的高级概述，有时也称为项目生命周期开发。它指定了在产品开发过程中必须进行的活动和必须生成的交付物。

需求分解和系统规范制定的过程表现为 V 模型的左侧。单独组件的集成和验证表现为 V 模型的右侧。然而，需求首先需要经过验证过程，在此过程中它们会与更高层次的需求或用户需求进行比较。此外，还有一个叫做系统模型验证的概念。你也可以通过“左移”来完成这一过程，这意味着根据团队的操作方式，验证只在右侧发生的说法可能并不准确。

在 V 模型中，时间和开发从左至右推进，且无法倒退。正如图中所示，所有迭代都发生在垂直方向上，要么向上，要么向下在框架的架构中进行。这两个过程的区别在于，验证是根据预定义的技术规范进行的，而确认是根据实际的世界条件或用户需求进行的。你可以通过确保你正在构建正确的东西来验证，并通过确保你在以正确的方式构建它来确认。

螺旋模型

1986 年，巴里·W·博姆创建了螺旋发布管理模型，作为组织软件开发生命周期（SDLC）的一种方法。该模型假设构建一个应用程序是一个可以无限重复的周期，直到达到预期的结果。通过持续监控风险和检查中间产品，螺旋模型显著降低了大型软件项目失败的可能性。

在开发过程中出现的问题可能会对最终产品产生多种潜在影响。如果发生这种情况，你应当为价格上涨、工作量增加以及交付日期延迟做好准备。这些都是可能迅速威胁到公司可持续性的因素。螺旋模型采取的迭代渐进方式，以及常规的风险评估（可以通过原型草图、研究或仿真来实现），旨在要么彻底消除此类事件的可能性，要么至少减少它们造成的损害。螺旋软件开发模型非常适用于大型、高度定制的项目，尤其是客户和开发者将财务管理作为优先事项，或是在高度波动的市场中的项目。与其他传统模型相比，螺旋模型的最大优势是风险分析，这对所有相关方都有益。常规的风险评估对于缺乏经验值且具有较高风险概率的创新技术环境尤为重要。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_03_5.jpg

图 3.5: 螺旋发布管理模型

软件开发项目会持续进行其螺旋模型周期，直到达到最终状态。这个周期主要包括以下四个步骤：

1. 螺旋模型典型周期的第一阶段是确定应与软件开发的各个阶段相关联的目标。增加功能或提升性能就是此类变更的示例。同时，必须明确几个实现选择（例如，设计 A 与设计 B 的对比），并确定框架条件以及所需的开销或时间。

2. 下一阶段是分析各种选择，以目标和框架条件作为权威的参考值。在螺旋模型周期的这一阶段，应识别和分析对软件项目整体开发构成重大风险的不确定性区域。原型设计、模拟、基准测试、分析模型和用户调查是将用于下一阶段的一些工具，这一阶段将开发出最小风险和最高性价比的策略。

3. 在完成全面的风险评估后，软件开发可以继续进行——但始终会存在一定程度的残留风险。例如，如果性能风险、用户界面风险或内部接口控制风险在开发过程中占据主导地位，第一种替代方案就是演化开发策略，在该策略中，项目将被更清晰地定义，并且原型得到优化。在这个策略中，用户界面风险和内部接口控制风险是主导开发过程的关键问题。然后，代码会被创建并多次测试，直到获得预期的结果，为之后的开发过程奠定一个低风险的基础。

演化原型开发

演化原型开发，也称为面包板原型开发，与其他原型策略有所不同。采用演化原型的主要目的是利用系统化的过程构建一个高度可靠的模型，并不断改进它。这一方法基于这样的理念：演化原型作为新实施系统的基础，使得未来的增强和附加需求可以随着时间的推移逐步整合进来。

1. 下一周期将在当前周期结束后立即规划。如果单个周期的目标能够实现，而下一个目标尚未确定，那么这可能是项目的常规延续。另一方面，如果前一阶段的开发存在缺陷，寻找解决方案可能是唯一的选择。当前方法的一个可能替代方案是已经确定的替代方案之一，或者引入一个全新的方法。通过这种方式，你可以再尝试一次，直到实现目标。

软件开发中的螺旋发布管理模型被认为是一种通用的过程模型。四个阶段仅仅是确立了一个周期的基本目标，并不要求每次迭代中都体现出来。它们的顺序并不是由螺旋模型严格决定的。因此，该模型有可能在任何时刻与其他过程模型进行集成。

这就是我们对螺旋发布管理模型的回顾。到现在为止，你已经了解了螺旋软件开发是一种规避风险的模型，主张实施迭代开发技术，并在 SDLC 的每一步中管理风险。接下来，让我们来研究一下大爆炸发布管理模型——一种与螺旋模型截然不同的高风险开发风格。

大爆炸模型

在大爆炸发布管理模型下，软件工程师在没有任何详细准备的情况下，全力投入到编程工作中。换句话说，没有预定的计划，需求是随着发现而逐步实现的。在某些情况下，如果需要调整，可能需要完全重写应用程序。你可以清楚地看到大爆炸模型为何得名。然而，当项目中只有一两个开发人员参与时，这种方法特别有效，正如在学术界或实践中的情况一样。当项目需求不明确且有一个固定的完成期限时，这种技术尤为有用。

大爆炸模型是一种软件开发生命周期范式，它从什么都没有开始，逐步构建起来。我们在规划上花费的时间非常少，也不遵循任何特定的程序。由于不需要任何规划，它是最基础的发布管理方法。需求是在没有太多前瞻性的情况下实时应用的，客户甚至不清楚自己需要什么。该方法的主要目标是尽快开始编码，而不遵循任何特定的结构，并尽快将完成的产品交付给客户。日常开发开始时有一些前提条件，尽管对最终结果知之甚少。接下来，客户与开发团队保持密切联系，以跟踪工作进展。如果结果与预期相符，产品将被授权；否则，将提出不同的解决方案。

简而言之，这种方法论不需要详细规定要求，产品需求在收到后会迅速被理解并执行。该范式的核心重点是编程，因此相比其他发布管理模型，它更容易受到风险的影响。在组件或至少其组成部分完全集成后，测试即可开始。此模型最适合在现有环境中整合前沿技术，分析所做的修改，并具有良好的适应性。

正如你所推测的，这个模型类似于宇宙大爆炸理论。时间、资源和能量的浓缩混合，瞬间产生了一个完成的产品，似乎是凭空而来。下图详细描述了大爆炸发布管理模型：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_03_6.jpg

图 3.6：大爆炸发布管理模型

这就是我们对大爆炸发布管理模型的回顾。到现在为止，你已经理解了发布管理的真正含义。你明白了发布管理可以是怎样的，从最正式到最非正式的形式。接下来，我们将探讨臭名昭著的敏捷发布管理模型。无论你喜不喜欢，敏捷模型在 DevOps 崛起并取代它之前，曾在大约二十年的时间里风靡一时。

敏捷模型

敏捷发布管理模型将 SDLC 阶段分为多个开发周期，团队在每个周期结束时交付增量的软件变更。敏捷方法非常有效，其快速的开发周期帮助团队及早发现问题；然而，过度依赖客户反馈可能导致范围蔓延。敏捷模型非常适合那些随着时间推移需要适应性和灵活性的软开项目。下图展示了敏捷模型：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_03_7.jpg

图 3.7：敏捷发布管理模型

大多数敏捷开发所使用的技术将工作划分为若干小增量。这些增量相比其他发布管理模型（如瀑布模型）需要较少的前期规划和设计时间和精力。这些迭代被称为冲刺，是短暂的活动周期，通常持续一到四周。每个迭代都需要一个跨职能团队的参与，团队会进行所有活动，包括规划、分析、设计、编码、单元测试和验收测试。在迭代结束时，利益相关者会看到一个已经具有功能的产品演示。这降低了整体风险，并使得产品能够快速适应新的环境。

目标是确保每次迭代结束时都有一个可用的发布版本（且 bug 数量较少），尽管每个迭代可能不会产生足够的功能来支持市场发布。当产品以增量方式开发时，相较于在产品最终交付日期临近时发生灾难性失败，它们在每次迭代阶段更具灵活性，可以早期并频繁地失败。可能需要多次修订才能发布产品或新功能。进展的最重要指标是有功能的软件。

采用敏捷方法论的两个主要好处是快速的产品开发和降低风险。因此，通过将产品以较小的增量发布到市场，可以减轻由于产品未能满足消费者需求而产生的风险。

这就是我们对敏捷发布管理模型的回顾。正如您所见，敏捷模型是迭代增量模型的逻辑继任者，同时也是通向 DevOps 发布管理模型的一个重要步骤。因此，接下来我们将讨论 DevOps 模型。

DevOps 模型

DevOps 发布管理模型包括一系列方法论，旨在整合 软件开发（Dev）和 IT 运维（Ops），以促进更快速和更频繁的软件发布。这种软件开发策略结合了沟通、自动化和分析。DevOps 方法论强调交付符合业务目标并满足客户需求的软件。通过利用快速反馈循环、相关的 关键绩效指标（KPIs）和迭代开发策略来实现这一点。虽然 DevOps 包括规划、设计、编码、测试和部署，但该模型的一个显著特点是它如何将持续集成、持续交付、持续测试和持续监控融入到软件开发生命周期中。以下图示展示了 DevOps 模型：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_03_8.jpg

图 3.8：DevOps 发布管理模型

发布管理在很大程度上依赖于精确的报告，以便跟踪需求、风险和障碍。它还确保项目的初始目标和目的在整个软件开发生命周期内都能得到实现。

采用 DevOps 原则自然会带来一个更完善的发布管理框架，进而为交付生命周期每个阶段的有效协作和测试制定行业标准的程序。人们往往将自动化视为 DevOps 中最重要的价值，但自动化应始终聚焦于提升人员的生产力。当人们致力于提高操作效率并减少人为错误的影响时，他们必然会以更高的速度发布可靠的服务。

在 DevOps 文化中整合发布管理使得企业能够实现加速、可靠和成功的软件发布。最终，这一现象有助于提高消费者的满意度，增进开发团队间的合作，并加速企业的扩展。

DevOps 和发布管理在软件开发、项目管理和 IT 运维方面有着密切的关系。DevOps 发布管理包括了对软件发布和交付周期的设计、规划、调度、测试和实施等活动的管理。

已经至少对某个产品进行过一次修改的组织，通常都能深刻理解发布管理在 DevOps 背景下的重要作用。当这一策略得当执行时，它有潜力提升开发、测试和操作过程的效率。此外，这一发布管理策略还能有效减少返工成本、加强协作并促进高质量产品的成功交付。

这提升了组织对发布过程各阶段的监督，从最初的开发到最终的交付。DevOps 发布管理现已成为当新产品推出或进行修改时的现代标准。DevOps 过程可能会因团队的不同、偏好的实践和组织的目标而略有不同。

通过采用 DevOps 发布管理，软件开发团队能够通过更早地进行质量检查、左移测试、自动化和 QA 程序，从而提高软件交付生命周期中的整体效率。由于其在消除孤岛效应、促进团队成员协作方面的作用，DevOps 发布管理正逐渐成为当前最流行的发布管理策略。

总结

我们已经到达本章的结束。到目前为止，我们已经讨论了 IT 行业中最常见的八种发布管理模型。它们分别是 ITIL 模型、瀑布模型、迭代模型、V 型模型、螺旋模型、大爆炸模型、敏捷模型和 DevOps 模型。现在你应该已经了解了每种发布管理模型的各种优缺点，并对选择适合自己项目的模型有了信心。此外，你也已经接触到 DevOps 相对于之前发布管理模型所提供的惊人好处。因此，你对发布管理的历史有了基本了解，并能够根据每种模型的演变，做出明智的结论。

本章已结束，第三章。在下一章中，我们将学习 DevOps 发布管理的独特性。了解这一点非常重要，因为接下来的章节将重点讨论 DevOps 发布管理模型。

问题

请回答以下问题，以测试你对本章内容的理解：

1. 为什么 ITIL 发布管理模型更多地与系统开发生命周期相关，而不是软件开发生命周期？

2. 第一个标准发布管理模型是什么？

3. 迭代和增量发布管理模型中的三个步骤是什么？

4. 在 V 型发布管理模型中，时间和发展的进程走向是什么方向？

5. 螺旋发布管理模型的定义特征是什么？

6. 大爆炸发布管理模型开始新项目时需要的三个关键要素是什么？

7. 敏捷发布管理模型在测试方面的座右铭是什么？

8. DevOps 发布管理模型的定义特征是什么？

9. 在瀑布发布管理模型中，何时可以回溯并返回到之前的阶段？

10. DevOps 发布管理模型的哪个阶段进行测试？

第二部分：DevOps 发布管理的优势

在本书的第二部分，我们将从学习 DevOps 发布管理试图解决的问题开始。接着，我们将学习 DevOps 发布管理的独特性。然后，我们将了解 CI/CD 的基础，它是基于 DevOps 的价值流的核心。最后，我们将探索 CI/CD 流水线如何促进良好的 DevOps 发布管理。本部分的目标是强调 DevOps 发布管理的标志性特征，以便你在进一步学习并成为一名经验丰富的 DevOps 领导者和战术专家之前，具备必要的基础知识。

本节包含以下章节：

• 第四章，DevOps 发布管理试图解决什么问题？

• 第五章，理解 DevOps 发布管理的独特性

• 第六章，理解 CI/CD 的基础

• 第七章，技术发布经理的实用流水线

• 第八章，CI/CD 流水线如何推动良好的 DevOps 发布管理

第四章：DevOps 发布管理试图解决哪些问题？

以今天的标准来看，传统的 IT 组织有着极长的开发周期。在这些过时的公司中，通常需要进行大量的手动测试，才能将软件产品发布到生产环境中。而且，每次代码变更都会给相关方带来极大的压力。在这些组织中，开发团队通常需要等待清理好的环境，或者必须等待批准才能进行任何变更。此外，质量保证（QA）团队可能要等开发人员完成工作后，才能进行测试。这些等待导致了低部署频率（DF）和高变更交付周期（LTFC）。

此外，在传统的 IT 组织中，项目完成后，许多团队成员会离开，几乎不留下文档或知识转移。这使得当新工程师加入团队并尝试支持系统时，面临很大挑战。通常，这会导致在发生关键问题时，平均恢复时间（MTTR）较长。像这些组织通常通过专门的运维团队来管理环境配置，这些团队的唯一任务就是基础设施管理。即使基础设施即代码（IaC）是公司的标准程序，他们仍然会进行手动更改服务器，导致配置漂移。不同环境中的服务器可能会有不同的工件，例如应用程序所需的库，或者相同产品的不同补丁级别。所有这些手动工作会导致低 DF 和高交付周期。

在本章中，我们将探讨 DevOps 发布管理如何通过结合自动化、最小化风险、简化发布过程，并通过跟踪度量标准和分析关键绩效指标（KPIs）来解决这些问题。我们将论证 DevOps 的特点如何使其在云端微服务部署的背景下，成为一种卓越的发布管理方法。

因此，本章将涵盖以下主题：

• 探索自动化测试、部署和变更管理

• 减少潜在风险并加速软件产品的发布

• 精简发布过程，使其标准化

• 改善成功发布的度量标准和关键绩效指标（KPIs）

探索自动化测试、部署和变更管理

当涉及到软件的创建时，大多数现代组织必须应对一些重大障碍：快速部署软件 和 规模化创新。DevOps 方法旨在通过在整个软件开发生命周期（SDLC）中实施自动化来解决这些挑战，其目标是加快交付既可靠又安全的软件。

通过合并自动化测试、自动化部署和自动化变更管理，DevOps 发布管理为运营团队铺平了自动化发布计划的道路。当使用自动化进行发布管理时，管理和交付成功的发布要简单得多，因为它使发布管理成为一个可以轻松重现和重复的过程。这通过实施精心设计的持续集成/持续部署（CI/CD）流水线来实现，在您的组织内部是互操作的，但同样重要的是它们是可靠的。

无可否认，自动化包含持续发布和持续交付的 DevOps 框架是多么复杂。在整个应用程序开发过程中，必须使用全面的测试、广泛的跨团队沟通、先进的工具和工作流程来实现持续发布。

在接下来的小节中，我们将讨论自动化测试这一至关重要的话题，这是 DevOps 理念的生命线。

自动化测试

在 CI/CD 流水线中尽早且频繁地部署自动化测试从 DevOps 的起源以来就成为其重要特征。这包括积极监控生产环境，以防止未检查的问题影响用户。现实情况是，现代应用程序依赖于多个可能故障的工件和服务。除了在流水线中使用静态和动态应用程序分析工具之外，还应在所有开发环境中进行事务性监控，而不仅限于生产环境。通过使用模拟数据和持续监控来运行测试，您可以检测到影响应用程序任何组件的问题，包括第三方软件即服务（SaaS）集成。一些有效的 SaaS 工具包括 Datadog、Dynatrace、New Relic、Snyk 和 Prisma Cloud。

随着您的开发团队逐步完善其 DevOps 实践，他们将希望在整个 SDLC 中实施测试自动化，因为这是释放 DevOps 全部好处的关键。这些好处包括能够更快、更一致地构建、测试和发布。为了提高事件响应（IR），鼓励团队之间的协作，并有效沟通，现在不再可行的是将新代码提交给手动 QA 测试几个小时甚至几天，然后再让软件开发人员得到反馈。QA 团队必须围绕 DevOps 发布管理生命周期调整工作，确保测试用例实现自动化，并且在可实现的范围内具有完整的代码覆盖。环境的配置需要通过使用基础设施即代码（IaC）来标准化，并且部署应当自动且不可变地进行。换句话说，所有的预测试任务，例如基础设施配置、环境配置、后测试任务、清理或相关的、可重复的、日常的事项，都应当实现自动化，并与 CI 的理念保持一致。

自动化测试是 CI 的关键优势，它能节省您的资源，使您能够实现规模经济。首先，自动化测试最大化了在错误进入生产环境之前被发现的可能性。它还通过在检测到缺陷和错误时立即通知您，来加快发布过程。此外，实施 CI 的一个显著优势是，小团队也能成功地完成更重的任务。并行集成允许您快速连续地执行多个自动化测试，每个测试通常只需几分钟，从而进一步减少测试开销。自动化整个开发过程可能看起来令人不知所措，但您可以从自动化一个单一的端到端流程开始，并定期运行它。新的工具和资源使自动化测试比以往任何时候都更容易，且其好处值得投入。自动化测试使您能够消除瓶颈并提高生产力，通常能够提升员工和客户的满意度，并增加公司银行账户中的收入。

自动化测试带来的一个重要推动力是能够以今天数字化市场的速度扩展运营。DevOps 技术在降低风险的同时，能保持一致的质量。这在一定程度上通过将工作分配给多个小型团队来实现，这些团队以自给自足的方式运作，同时又能像一个有凝聚力的部落一样进行协作。这种共同开发风格鼓励团队成员分享个人技巧和想法，同时在作为业务单元（BU）的共同理念下工作。由于自动化测试带来的巨大生产力提升，你将体验到更好的团队协作。你的同事不再需要将大量时间和精力投入到手动测试协议中，反而团队将有更多机会讨论优化策略，或是一起外出享受兄弟般的午餐。由于你选择了 DevOps 文化，你也选择了共同承担质量责任，这种责任感在团队成员中培养了自豪感。现在，你应该能意识到自动化测试已成为 DevOps 的重要组成部分。

DevOps 发布管理可以帮助你提升基础设施和业务流程的可靠性。更重要的是，通过提高测试自动化覆盖率来改进发布的可靠性，生产环境中的问题将变得非常罕见。这些特性总和促成了一个令人振奋的工作环境，团队成员也更喜欢这种工作方式。所有这些 DevOps 发布管理方法的特点都带来了客户的更高满意度。事实证明，更好的可靠性和快速响应客户反馈能提升客户满意度，并鼓励更多人推荐你的公司产品。

自动化部署

从本质上讲，CD 是一个统一的发布过程，包含了自动化构建、测试和部署步骤。其目标是简化将新软件推向生产环境的操作流程。每个企业必须弄清楚其独特的测试套件中，单元测试、功能测试和压力测试的组合方式。为了成功地进行构建和发布候选版本的预部署测试，必须在发布前的预生产测试环境中模拟生产环境条件。

通过使用 CD 流水线，可以将代码更改自动推送到生产环境，CD 流水线是一种自动化工作流，结合了构建、测试和部署。一个工作流阶段的输出成为下一个工作流阶段的输入，依此类推。通过 DevOps 方法，CD 可以通过在每个阶段进行自动化测试和监控来预防错误、功能难题和缺陷。通过这种方式工作，可以在问题进入主分支之前及时发现并解决，从而避免其影响生产环境。

最终结果是，工程团队能够将代码修改实施到主分支，并迅速在生产环境中看到其部署，通常在几分钟内完成。这种软件开发的哲学强调 DevOps 的根本目标，即持续为最终用户交付价值。这一因素也成为许多应用程序和基于网络服务中新特性和系统修改引入的主要催化剂。

一旦实施，CD（持续交付）使企业能够更容易地满足客户期望，并迅速发布软件升级，通常在提交代码更改后的几分钟内完成。然而，采用 CD 可能会与传统的需要花费几天甚至几周时间准备发布软件的方法相比发生巨大的变化。尽管如此，那些投入必要的努力、资金和设备的公司将获得实实在在的好处。以下是一些广泛认可的采用 CD 的好处：

• 完全自动化产品发布的实施：这使企业能够将更多时间分配给软件开发，而不是在发布日之前中断开发活动。

• 应当有更频繁、更小规模的发布：这不仅能使产品开发工作进展得更快，还有助于支持持续改进的范式。

• 与新实现的功能相关的快速反馈循环：组织能够迅速收到关于新特性、升级和代码修改的实时反馈。

自动化变更管理

一个从 DevOps 方法的特别应用中获益匪浅的传统流程是变更管理。许多现有的变更管理方法直接与 DevOps 哲学的基本原则相悖。传统策略引入的官僚主义和审批关卡，要求每次变更都经过多个级别的审批，这几乎确保了更长的发布周期和延迟向客户交付价值。这与 DevOps 哲学相悖，后者强调快速迭代和频繁的客户获益。为了有效实施 DevOps 策略来管理变更，我们必须放弃传统的、封闭的稳定性维护观念。要充分理解变更管理如何在保持一致性的同时促进快速响应和适应性，我们必须扩展我们的视野。我们不会将变更审批过程作为阻碍创新的障碍，而是将其作为加速向客户交付新特性的过程的一部分。

通常，你将与采用 CI/CD 方法的组织打交道，这使得它们能够每天进行多次发布，有时甚至达到两位数或三位数。为了在快速速度下有效实施变更管理，必须将其整合到 CI/CD 流程中。有几种IT 服务管理（ITSM）工具，如 ServiceNow、Jira、Freshservice 和 Zendesk，提供应用程序编程接口（API），使得 CD 管道与变更管理系统之间能够无缝集成。通过利用这些 API，组织可以自动生成变更票据，并通知相关方参与。这一做法保证了每次修改都有一个票据，而不会对部署过程造成额外负担或阻碍。许多企业已经成功地实现了流程结构、协作文化和变更管理工具的融合，为实现稳定的操作环境铺平了道路。

向管道中添加审计日志是一项简单的操作，并且带来了显著的优势。实施审计日志后，任何有兴趣的人都可以查明最近一次修改上线花费了多少时间，为什么它是必要的，谁批准了它，是否所有前阶段的检查项都已经完成。例如，当审计员要求提供文档，证明某个变更在未来遵循了你的流程时，你只需追溯日志记录即可。你可以对所有信息配置精细的访问权限。然而，随着这些优势而来的是重大的挑战，尤其是在需要绕过变更管理门槛，在紧急情况下对生产环境进行手动更改的情况。

这就结束了我们对自动化测试、部署和变更管理如何极大改善传统软件开发实践的探索。在下一部分，我们将讨论 DevOps 如何降低风险并提高开发速度。

降低潜在风险并加速软件产品的发布

软件交付过程通过 DevOps 发布管理得到了卓越的沟通、协调和生产力的促进。Slack、MS Teams、Jira、Confluence、ClickUp、Asana等协作工具促进了优异的沟通，这一点非常重要，因为在当今全球化经济中，各组之间的协作发生在广阔的距离和时区之间。

DevOps 发布管理方法的典型实施包括了诸如 CI/CD 和部署自动化等成熟的工作方法，这些方法大大加快了高质量软件的开发，同时减少了潜在风险。因此，这些因素使企业能够迅速适应市场波动，以更高效的方式满足消费者需求。

在 DevOps 实践特别有用的几个领域中，灾难恢复（DR）尤为重要。自动化流程、实施 CI/CD 以及利用云计算对于保证 99.999%的正常运行时间且不丢失数据至关重要。当灾难恢复计划成为组织 DevOps 管道战略的一部分时，它通常与应用程序本身一起管理，以便定期对两者进行检查。通过在 DevOps 工作流中加入灾难恢复计划，恢复过程实际上被转变为类似于部署应用程序的过程。这不仅减少了错误的可能性，还帮助加速了新软件应用程序的发布。在危机发生时，你的团队可以利用他们在部署方面的专业知识来促进恢复过程。

此外，复制数据的灾难恢复环境也能为恢复工作提供帮助。毫无疑问，用于将应用程序从开发、QA 到生产环境的工具和程序，也可以应用于灾难故障切换和恢复工作。这确保了选择采用 DevOps 的决策同样为灾难恢复（DR）方面带来了有价值的投资。最终结论是：同样的自动化技术，可以用于将应用程序从开发/测试环境过渡到生产环境，也可以用于故障转移和恢复。

这段内容总结了 DevOps 发布管理如何减少风险的潜力并加速软件产品的发布。在接下来的部分，我们将探讨 DevOps 如何通过标准化发布过程最大化自动化的效益。自动化是一个方面，但如果没有优化这些过程，你将失去管道所能提供的最大利益。

精简发布过程，使其变得标准化

通过将发布管理纳入现有的 DevOps 工作流中，发布过程可以得到简化，最终实现标准化。这为公司程序的统一执行设立了先例。建议将 CI/CD 管道的结果记录在发布日志中，并将其汇总到发布管理的故障跟踪产品、源代码管理以及相关工具中。在系统部署后，这些文档对于追踪问题的来源并应用相应的解决方案至关重要。

发布管道一词指的是一系列自动化和手动流程，旨在确保客户能够访问到公司软件产品的稳定和安全版本。发布管道的职责和责任是确保产品改进能够快速、安全地交付给最终用户，从源代码的更改开始，通过开发、测试和发布的过程。持续交付（CD），确保您的代码库可以随时安全部署的过程，与发布管道密切配合。原因在于它们减少了开发人员必须花费在繁琐工作上或修复不可避免的错误上所需的时间。

发布管道最显著的优势是它能在保证稳定性的同时缩短交付新版本所需的时间。如果出现问题，您将有自动回滚程序和防故障机制。总体而言，您的用户将更早获得新功能（或错误修复）。通过发布管道，可预测性和可靠性都得到了提高，开发人员生产力的提升也是另一个优势。开发人员可以避免在事后为自己的行为辩解或重构发布版本，因为内置的审计功能可以减少这些麻烦。他们将有更多时间专注于编写代码（这一活动为业务带来价值），而无需过多担心外部细节。

发布管道充当公司软件分发的协调者。这意味着该系统将根据发布获取的输入和数据自动做出决策。此外，它还将实时解决常见问题，或者在某些情况下，如果发现对客户有不利影响，立即回滚部署。发布管道是根据您公司业务运营的独特需求和管理框架量身定制的。该工具能够提供全面的反馈和有价值的指标，增强对整个发布过程的整体意识；这种可见性是任何其他方式无法实现的。

协调的发布管道的实施促进了准确预测项目结果的能力，并最终验证其成就或不足。运营团队，通常会根据发布速度、效率和效果进行评估，也可以从发布管道中受益。发布管道比脚本化部署更快，对资源的消耗也更小，越来越受欢迎。这是因为它们减少了风险，并在出现问题时加入了自动修正程序，从而减轻了运营团队最难处理和最琐碎的烦恼。

这段内容概述了 DevOps 发布管理如何简化发布过程。在接下来的部分中，您将看到如何量化衡量成功。这些可以用于验证您的流程是否在改进，并向高级管理人员展示价值。

提升成功发布的指标和关键绩效指标（KPI）

通过设定标准，DevOps 发布管理有助于开发出更优秀的软件发布。通过自动化、版本控制和质量控制（QC），开发团队可以深入了解生成更多频繁发布、且失败率较低所需的指标。

无论是在 DevOps 还是在其他任何领域，都有一个道理：无法衡量的东西是无法改进的。DevOps 最有效的方式是团队收集、分析并衡量各种数据，以便实现更快、更高质量的产品交付。这些 DevOps 指标提供了 DevOps 团队控制软件开发生命周期（SDLC）所需的关键信息。DevOps 软件开发中的指标突出显示了管道的效率，并可以及时消除阻碍进展的任何障碍。这些指标可用于监控技术能力以及运营效率。

DevOps 的主要目标是消除开发与运维团队之间的区别，从而促进软件开发人员与计算机系统管理员之间更紧密的协作关系。指标使 DevOps 团队能够客观地衡量和评估协作工作流，并跟踪实现高层目标的进展，例如增强应用性能、加速发布周期和提高质量。

四个关键的 DevOps 指标

通过DevOps 研究与评估（DORA）指标框架，可以有效衡量软件开发、交付和维护的成效。组织可以使用这些指标作为不断改进 DevOps 性能的起点，并实现更好的业务成果，因为它们能揭示哪些团队表现卓越，哪些团队表现较差。DevOps 和工程经理通常能较为清楚地了解团队的表现，但他们更难衡量团队为公司带来的价值，并找出改进的方向。借助 DORA 指标，软件交付性能可以得到客观衡量和优化，且可以证明其对业务的价值。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_04_1.jpg

图 4.1：示例 DORA 指标仪表板

DORA 方法包括四个关键指标，接下来将详细介绍，用于评估 DevOps 的两个基本维度：即速度和可靠性。DevOps 团队的速度通过他们的 DF 和平均 LTFC 来衡量，而 DevOps 团队的可靠性则通过他们的变更失败率（CFR）和恢复服务时间（TTRS）指标来衡量。当这四个 DORA 指标一同分析时，它们为 DevOps 团队的成功提供了基本的衡量标准，并提供了可能需要改进的领域的指示。

LTFC

LTFC 被认为是 DevOps 团队必须监控的关键指标之一。LTFC 的概念不应与周期时间混淆。LTFC 指的是从代码更改提交到主干分支的时刻开始，到该代码更改变得可部署的时刻之间的持续时间，例如，当新代码成功完成所有必要的预发布测试时。

通常，表现卓越的团队倾向于将交付周期量化为小时，而表现不佳的团队则将交付周期量化为天、周甚至月。提高周转时间需要结合使用测试自动化、基于主干的开发、精心设计的反馈回路以及迭代、增量式工作。只有遵循这些原则，开发人员才能迅速评估代码的质量，并在代码发布前修复任何发现的缺陷。当多个开发人员在不同的分支上并行进行重大更改，并依赖人工测试来确保质量时，交付周期不可避免地会膨胀。

CFR

引起问题并需要修复的代码更改的百分比称为 CFR。这不包括在测试中发现并在代码发布之前修复的错误。

高效的团队通常展示出 CFR 位于 0%到 15%之间。较低的 CFR 与使用相同方法（如测试自动化、基于主干的开发和小批量工作）相关，这些方法能缩短交付周期。实施这些流程的结果是，发现和修复错误变得更加轻松。监控和报告 CFR 不仅对于定位和修复问题至关重要，而且还能确保新发布的代码满足所有必要的安全标准。

DF

DevOps 的成功在很大程度上可以通过新代码进入生产环境的频率来衡量。许多专业人士使用交付这一词汇来指代代码更改发布到预生产阶段环境，而使用部署来指代代码更改发布到生产环境。

最优秀的团队能够根据需要随时推出更新，通常一天可以多次更新。表现较低的团队通常只能每周或每月进行一次部署。具备按需部署能力需要配备自动化部署流水线，该流水线不仅包含前述的自动化测试和反馈机制，还减少了所需的手动干预。

MTTR

被称为 MTTR 的指标量化了在部分中断或完全故障后恢复操作所需的时间。无论中断是由于最近的部署、单个服务器故障还是介于两者之间的其他原因，跟踪这一指标都是至关重要的。高效的团队通常能在不到 1 小时的时间内从系统故障中快速恢复。相反，表现较差的团队可能需要长达一周的时间才能完全恢复。

对 MTTR 的重视标志着与传统上强调平均故障间隔时间（MTBF）的做法的不同。这反映了当前程序的复杂性以及它们发生故障的可能性。此外，这还鼓励了不断追求更好的习惯。团队现在不断进行部署，而不是等待发布“完美”以避免任何故障。与其为表面上完美的 MTBF 记录中断寻找替罪羊，MTTR 提倡无责的回顾会议，帮助团队改进上游过程和工具。

周期时间，或产品从团队开始工作到最终发货所需的时间，是另一个需要跟踪的相关统计数据。从开发人员提交代码到代码推送到生产环境所需的时间被称为“开发周期时间”。这个重要的 DevOps 指标对于项目经理和工程经理来说非常有用，帮助他们了解开发流水线的成功因素。这样，他们就能确保团队的工作更符合利益相关者和客户的期望，从而更早地发布产品。

项目经理可以使用周期时间报告来定义 CI/CD 流水线的基础基准，随后可以用来评估未来的操作。当团队优先优化周期时间时，开发人员通常会减少在制品（WIP）的数量，并减少浪费活动的发生。

总结

在你期望有效运用 DevOps 发布管理之前，理解 DevOps 发布管理旨在解决的问题至关重要。阅读完本章后，你应当对 DevOps 生命周期中的许多关键方面有一个基础的了解。你现在明白了在测试、部署和变更管理中融入自动化技术的重要性。此外，你还了解了使用发布管道来减少潜在风险并加速软件产品发布的策略。同时，你现在也明白了为了以标准化的方式简化发布过程，需要采取哪些步骤。最后，你掌握了改进成功发布和客户满意度的度量标准（KPI）所需的基础知识。

在下一章中，你将学习到 DevOps 发布管理与其他发布管理模型相比的独特本质。通过学习 DevOps 发布管理哲学，你将理解它与众不同的关键差异。你将了解为什么 DevOps 是整体的，并且在你的组织中需要文化上的意义。此外，你还将理解 DevOps 用来集成 CI/CD、质量保证、安全性和反馈回路的颠覆性策略。你还将了解到 DevOps 如何将业务团队纳入开发过程的重要性。进一步，你将接触到 Gene Kim 的 三种方式 DevOps 原则。最后，你将了解到传统发布管理方法与 DevOps 的差异。

问题

回答以下问题以测试你对本章的理解：

1. 持续部署和持续发布之间的区别是什么？

2. 审计追踪是什么？它们的好处是什么？

3. 在 DevOps 发布管理生命周期中，自动化测试最合适的阶段是什么？

4. 在 DevOps 发布管理方法中，如何处理变更审批过程？

5. 发布管道的作用是什么？

6. 如何在 DevOps 发布管理方法中融入 DR 策略？

7. ITSM 工具如何自动化变更管理？

8. 四个 DORA 指标是什么？

9. 在 DevOps 发布管理方法中，如何最佳地融入发布日志中的数据？

10. 如果有一个 DevOps 指标是最重要的，那会是哪一个？

第五章：理解是什么让 DevOps 发布管理与众不同

DevOps 文化是全方位的，它涉及到审视价值流的每个环节并对其进行优化。DevOps 的哲学旨在消除孤岛效应或个别团队的孤立工作。因此，拥抱 DevOps 文化的企业提高了端到端操作的透明度。这与许多成熟企业的做法背道而驰，因为这些企业中，个人和团队有着明确的角色和职责，很少进行跨部门协作。

DevOps 的哲学是集体责任，鼓励 IT 人员快速找到解决方案，并始终致力于终身学习。Gene Kim、Jez Humble、Patrick Debois和John Willis，《DevOps 手册》的作者，在书中概述了这些基本原则。员工应该能够将大部分时间用于完善与 DevOps 相关的任务，如基础设施自动化、网络安全、应用监控和补丁修复。持续改进的驱动力是 DevOps 文化的核心。如果您的团队在正确执行 DevOps，高压时刻和职业倦怠是罕见的现象；否则，您的业务单元可能在资金上被严重压缩。

然而，企业领导层通常对风险较为回避，因此当某个流程证明有效时，他们通常会紧紧抓住它，并视而不见。DevOps 团队的任务是根据一套流程优化效率。这也是为什么 DevOps 团队必须与业务开发团队密切合作，确保公司产品的稳定性、性能和安全性。

在本章中，您将深入了解 DevOps 的独特方面，我们将涵盖以下主要内容：

• DevOps 是全方位的

• DevOps 整合了 CI/CD、QA、安全和反馈

• DevOps 将业务团队纳入开发过程

• DevOps 的三种方式

• 传统的发布管理方法与 DevOps 相比如何？

• DocuSign 如何从敏捷转向 DevOps 的案例研究

DevOps 是全方位的

DevOps（开发与运维）倡议是全方位的，与过去的孤立策略不同。DevOps 考虑的是整个价值流和所有相关的人员，而不仅仅是某一个人或其中的某个特定组件。我们通过围绕员工设计我们的系统和流程，颠覆了传统模式。这也是为什么表现卓越的 DevOps 团队能够证明信息技术投资与财务表现之间存在相关性。投资的根本目标是促进和赋能个人，使他们能够改进流程并为自己选择合适的技术。赋能员工直接与提高生产力和增强公司韧性相关联。

DevOps 领域已经经历了显著扩展，其范围超越了单纯的发布和部署过程。在撰写本文时，它涵盖了各类利益相关者，包括产品负责人、项目经理，以及软件开发生命周期的各个方面。这一主要因素促使其作为一种整体方法论不断增长，涵盖了业务运营团队与客户之间的关系，以及产品发布和生产监控的各个阶段。DevOps 发布管理是 IT 行业中的逻辑进展，强调其在提升各行业组织绩效方面的有效性。

DevOps 的实施已经扩展到涵盖企业中的各个部门，包括客户支持、营销、产品负责人、项目经理、程序经理、开发人员、质量保证团队、发布或构建团队以及基础设施团队。DevOps 的主要目标是提高客户满意度并加快交付速度。因此，所有相关方必须全面了解整个过程，包括运营、规划、集成、测试、监控、交付和反馈。高效的流程和工具集成是自动化顺畅交换和执行信息的必要条件。这种方法还使得所有利益相关者能够更有效地为产品的成功和高效实施做出贡献。

DevOps 倡议的成功依赖于许多人有效地协同工作。这意味着组织必须尽可能消除所有信息和执行的隔离。初创公司通常会因为从零开始建立公司运营的优势而采纳 DevOps。然而，最近的宏观经济指标显示，越来越多的大型、成熟的企业正在采纳 DevOps 实践，尤其是为了优化效率、提高软件发布的频率和质量。

DevOps 领域涵盖了广泛的工具，其中很大一部分是源于开源。这样的发展为工程师提供了前所未有的工具选择，可以参与黑客攻关或实验。然而，这一现象通常带来独特的困难，因为过多的工具集可能会在工作流中创建孤立的知识和执行隔离，导致模糊性和浪费。这一现象变得越来越普遍且具有问题性，迫切需要转向提供更优集成和执行能力的解决方案，适用于各种技术。对于这种情况，最佳的做法是使用一个提供广泛集成能力的平台，如 GitLab、GitHub Actions、Plutora，甚至是 Zapier。

为了提供全面的解决方案，从客户需求开始到收到产品反馈，企业需要一个综合集成平台，允许在不同工具之间无缝集成和执行，包括内部的专有工具。这种方法对于成熟企业尤其有用，因为它让他们有自由保留现有的工具和流程投资，同时有针对性地引入新技术。成熟企业可以在不从头开始的情况下管理变革，同时专注于效率、自动化、协作、更高的发布标准和更频繁的发布。

DevOps 发布管理确保所有相关方都清楚哪些功能将会发布以及何时发布。这种方法包括强大的可追溯性功能、分析和仪表板，帮助了解信息和任务执行的从左到右的流动。减少对其他团队的依赖并促进自助服务的一种好方法是紧密集成数据系统、基于 CI/CD 的自助服务终端，以及通过运维专家的支持来自动化日常业务流程。

DevOps 使团队通过更好的端到端可视化和强大的协作方法提高生产力和效率，从而赋能每个团队成员。包容所有人还有一个额外的好处，就是改善了相互信任与合作的氛围。这种方法使得 DevOps 组织能够超越软件开发的构建和发布阶段，渗透到整个软件开发生命周期中。这对于大企业尤其有帮助，因为它保护了现有投资并改善了现金流。它为组织提供了频繁测试新工具和技术的可能性，同时保留那些有效的工具和技术。简而言之，全面性对于加速大型组织的数字化转型非常有利。

现在你已经了解了为什么 DevOps 是一种全面的实践，让我们深入探讨一下它如何不仅仅局限于人员，还要仔细考虑流程和技术。

DevOps 集成了 CI/CD、QA、安全性和反馈

DevOps 是一组消除软件开发与运维团队之间沟通障碍的技术，总体上旨在提高产品交付速度和质量。软件必须符合最终用户和利益相关者的要求和期望，这也是为什么质量保证（QA）是 DevOps 的一个重要方面。然而，将 QA 融入 DevOps 工作流中可能会很困难，因为这需要改变思维方式、公司文化和软件。

关键的是，在开发 DevOps 测试流水线之前，必须设立质量目标和关键绩效指标（KPIs）。了解你的 KPIs 的重要性不言而喻；每个独特的企业都有其自己的 KPIs。将质量目标与业务目标和客户需求对齐是任何公司面临的挑战。与你的团队成员及其他相关方分享质量目标，最好能够明确你想在质量方面实现什么目标，这可以帮助你集中 QA 工作，确保团队成员的步调一致。

如你在上一章中学到的，自动化是 DevOps 哲学的基本原则之一，因为它促进了软件部署的加速和标准化。此外，自动化在测试领域也发挥着至关重要的作用，因其能够减少人为错误、优化时间和资源的使用，并提供及时反馈。值得注意的是，明智之举是最大化自动化在整个测试流程中的应用，涵盖多个类别，如单元测试、集成测试、功能测试、性能测试、安全测试和回归测试。此外，建议使用支持自动化的技术和框架，例如JUnit、Cucumber、Selenium、Cypress、TestNG、SonarQube、Nessus、linters等。

再次强调，集成是 DevOps 的一个重要组成部分，其中测试工具与开发和部署系统的兼容性和互操作性至关重要。通过这种方式，建立一个贯穿整个软件开发生命周期的连贯且不间断的测试流水线是切实可行的。建议将测试工具与监控和报告技术（如 Splunk、Grafana 或 ELK）结合使用，以收集和分析有关软件质量和性能的数据。当然，使用具有更强追踪能力的综合 SaaS 产品也是不错的选择。通过将测试工具融入工作流程，你将提高测试过程的效率、透明度和团队成员之间的协作。

在 DevOps 的背景下，反馈起着至关重要的作用，因为它加速了问题的识别和解决，提高了流程效率，并使得从过去的错误中学习成为可能。建议在测试流水线的每个阶段都融入反馈循环，从代码审查到生产部署都不例外。积极推动从多方获取反馈，包括团队成员、消费者和利益相关者，都是值得提倡的做法。实施专门设计用于简化反馈收集和管理的技术和平台，如 GitHub、Bitbucket、Confluence、Jira、Slack 或 Teams，尤其具有显著的好处。实施反馈循环有望培养一种持续发展和创新的文化。

你可能听说过一个常用的流行词shift-left。在软件开发中，采用shift-left 方法意味着在流程的早期阶段尽早开始测试，而不是等到最后才进行。通过这样做，你将能够更快地发现和修复软件缺陷，减少不必要的返工和浪费，并提供更高质量的软件。当你选择 shift-left 方法时，你必须做的一件事是尽早将质量保证团队融入到整个过程，并将他们纳入计划、设计和开发阶段。简而言之，如果你shift left，你可以提高测试的成功率、有效性和覆盖范围。

像计划、编码、构建、测试、发布和部署等阶段通常会包含在 DevOps 流水线中，但它们之间的区别有时可能会变得模糊。当采用被称为DevSecOps的策略时，DevOps 发布管理生命周期中的每个阶段都会受到一套独特的安全标准和评估的影响。让我们讨论将 DevSecOps 集成到 CI/CD 流水线中时执行的安全检查：

• 计划：在项目开发的初期阶段，进行全面的安全分析并制定战略计划非常重要。需要确定许多因素，这些因素决定了测试将如何进行，包括具体的位置，并考虑这些活动将如何影响交付时间表。一个方面是使用威胁建模来检查可能的安全风险并制定对策。另一种方法是从一开始就主动将安全性融入到产品设计中。这意味着要尽早做出关于数据卫生和其他安全措施的重要决策。

• 编码：DevOps 发布管理模型的编码阶段是制定鼓励防御性编程的指导方针，并帮助开发人员立即应对安全和合规问题的理想时机。处理可能存在风险的代码区域（如内存缓冲区内的操作、NULL 指针引用，或其他输入验证、反序列化不可信数据等一般性标准）可能会纳入此类别。此外，建议使用 linting 工具来标记编程错误、漏洞、风格错误和可疑构造。同时，不要忘记在版本控制仓库中添加安全控制，以增强密码和 API 密钥的安全性，或防止对代码的未经授权修改。

• 构建：通过在构建阶段包括自动化安全检查，典型的管道可以在源代码到达主分支或生产环境之前检测到漏洞。例如，您可以执行 静态应用程序安全测试 (SAST) 工具，如 SonarQube、SAST-Scan、Snyk、Prisma Cloud 等，来分析代码。如果工具识别出任何漏洞，构建将会停止，并会发送一份报告通知团队管道失败的结果。这些操作允许开发人员在继续之前立即解决问题。

  此外，为了发现软件依赖中的漏洞并跟踪代码库中的开源组件，管道还应包括 软件组成分析 (SCA) 工具。这些技术共同高效地识别代码漏洞，从而确保它们在部署到生产环境之前得到修复。市场上有许多此类工具，包括商业工具和开源工具，它们专门设计用于审查当今最流行的编程语言。

• 测试：DevOps 从业者通常会建立一套自动化测试用例，旨在通过开发过程中的强质量保证协议来实施。这些测试用例是用于确认软件应用程序预期功能的一系列条件或操作的文档，可以通过手动或使用自动化工具如 Selenium、Cypress、Playwright、Puppeteer、Taiko、Appium、Espresso 和 XCUITest 来执行。为了管理测试过程的时间表和结果，您应使用如 BrowserStack、Testiny、JIRA 和 Xray、LambdaTest、Pivotal Tracker、TestRail、Kualitee、TestCollab、Zephyr 等测试用例管理工具。这些工具管理并跟踪在管道测试阶段识别的任何问题。构建基本单元测试以检查安全漏洞，例如程序如何处理无效或意外输入，是该过程的标准部分。

  此外，通常会结合应用程序安全检查，这些检查会在程序运行时扫描其漏洞。通过将安全措施与功能性并行实施，测试阶段变得更加全面。在应用程序测试过程中，动态应用程序安全测试（DAST）技术被用来主动测试正在运行的应用程序是否存在安全漏洞。常见的工具包括Acunetix、Appknox、Checkmarx、Detectify、Intruder、Rapid7和Veracode 动态分析等。这些工具旨在识别通常与用户身份验证、授权、跨站请求伪造、缓冲区溢出、SQL 注入、API 相关端点以及其他多种漏洞相关的问题。如你所见，这里列举的质量保证工具实在太多，无法在本书中一一详述。你需要与团队合作，评估这些工具，确定哪些工具与贵组织的工作方式和战略目标最为契合。

• 发布：在发布阶段，安全分析工具用于进行自动化安全测试和渗透测试。工具如Astra Pentest、Burp Suite、Metasploit、Nessus和OWASP ZAProxy被用来识别在之前阶段可能未发现的潜在问题。某些组织还遵循最小权限原则，确保个人和工具只被授予执行其职责所需的必要资源，绝不多给予。

• 部署：在成功执行早期测试后，必须继续进行安全基础设施的交付或为最终部署构建生产环境。在部署阶段，确保代码只有在通过每个前阶段的安全检查后才部署到生产环境。一个明智的做法是对应用程序代码和底层基础设施应用额外的自动化测试，作为额外的安全保障，以防在生产环境中部署了未经授权的代码更改，无论是故意还是无意。这可以帮助识别和解决生产软件中的运行时安全问题，无论在什么情况下。

• 操作与监控：在 DevOps 流水线的操作与监控阶段，组织通常依赖应用程序和基础设施指标来检测任何可能表明存在安全事件的异常活动。当发生安全事件时，日志记录、监控和警报可以帮助识别问题、评估其影响并协助恢复。

拥抱 DevSecOps 需要文化上的转变，使得安全成为所有参与软件开发生命周期的利益相关者的基本考虑因素。为了实现这一目标，组织通常会实施新方法并建立一个 DevSecOps 工具链，在整个软件开发生命周期中集成自动化安全检查。

以 DevSecOps 为中心的工具扩展了现有的 DevOps 方法，如 CI/CD、自动化测试实践、系统监控和简化的配置管理，通过无缝集成以安全为重点的工具和技术。接下来，我们将探讨在 DevSecOps 工具链的背景下，区分其作为 DevOps 整体实践下一个独特子集的关键要素。

就以 Webhook 为中心的安全策略而言，任何 DevSecOps 方法的主要目标是通过触发预提交和合并 Webhook 的自动化检查，主动识别和解决代码问题。组织可以选择部署多种类型的评估，具体如下：

• 分析源代码：SAST 是一种通过分析静态源代码（即在程序未运行时）来发现潜在漏洞的方法。

• 分析应用程序漏洞：DAST 通过将软件部署到沙箱环境中来工作。动态应用程序扫描技术可以监控软件对已识别漏洞的反应。

• 秘密扫描：有时，秘密信息会出现在提交中，无论安全政策多么严格。通过将秘密扫描工具嵌入到软件开发者的 IDE 中作为插件，或者在版本控制平台（如 GitHub）中直接分析（如果此功能可用），可以在提交之前识别秘密。此外，许多秘密扫描产品与 SCA 工具兼容，这些工具用于识别任意代码库中的开源软件依赖项可能存在的漏洞。

• 运行时应用程序自我保护（RASP）：运行时验证工具或 RASP 会持续监控并检测在生产环境中运行的应用程序所面临的直接威胁。通常，它们会提供实时报告，指示是否发现漏洞以及发现漏洞的具体位置，并附带时间戳。

就配置管理而言，采用基础设施即代码（Infrastructure as Code）是 DevSecOps 实现消除系统配置不确定性的常见方式。自动化配置文件扫描、版本控制的基础设施和自动化服务发布都可以通过 Docker、Terraform 和 Ansible 等工具实现，这些工具使用另一种标记语言（YAML）语法编写声明式配置文件。

• 编排基于容器的微服务：为了更好地处理复杂的云原生应用，公司在某些情况下可能会选择采用微服务架构。为了安全且高效地做到这一点，你需要容器编排平台来管理多个容器，并根据需要进行扩展或缩减。为了管理容器之间的通信，容器编排技术（如配置管理解决方案）通常使用 YAML 文件格式来进行配置。这些配置也可以使用安全扫描工具进行分析，以检测和修复漏洞。

• 监控和报告：这一测量过程包括记录应用程序和基础设施层级的所有信息，是 DevSecOps 工具包中最直接却极为有效的组成部分之一。顶级工具在问题发生时能立即提供洞察，并且具备强大的报告系统，能够在早期阶段检测问题。如果外发数据从意外端口发送，识别潜在的安全问题可能会变得非常困难。没有合适的监控和报告，就很难发现此类事件。

我们经常在不小心的情况下编写安全漏洞，同时将含有安全漏洞的开源软件库导入到我们的项目中。每天都有很多程序员在编写代码，而手动审查往往跟不上进度。这正是 DevSecOps 真正发挥作用的地方。它确保我们的软件交付物始终得到自动化的安全保障。

为了验证你的团队每次提交的代码，你可以使用持续交付管道来实现持续一切的理念。你的持续管道将从增加自动化安全检查中受益，这些检查提供早期警告通知，并且能够在软件交付生命周期的任何时刻轻松发现安全漏洞。许多持续安全技术能够与组织的成长相匹配，无论是大规模还是小规模的组织。

在 DevOps 中，人员和文化与工具和流程同样重要。如果你想实现质量目标并为客户提供价值，你需要与不仅仅是你团队中的同事，还要与跨职能协作的其他团队进行合作。你还应该努力建立一个注重信任、开放和责任的文化。这种文化应该是一个每个人都为质量贡献并承担责任的环境。除此之外，你还需要激发一种学习文化，让每个人都愿意获取新的知识、技术和方法。通过与你的团队进行协作，能够建立一个展现出高效交付速度和敏捷性的 DevOps 组织。

现在你已经理解了 DevOps 如何全面地融合人员、流程和技术，让我们进一步扩展这一主题，讨论如何将非技术团队成员（如业务部门）的反馈和合作纳入其中。

DevOps 将业务团队融入到开发过程中

DevOps这个术语不仅仅指允许你将应用程序持续部署到生产环境中的技术流程和工具——它的范围远不止于此。如前所述，DevOps 是一种全面的战略，组织的每个层级都需要认识到 DevOps 方法论的合法性。为了确保 DevOps 融入每个项目，销售和营销部门需要将其作为工作流程的固有组成部分，并且必须严肃对待。同样，将有效的 DevOps 实践应用于多个部门也是至关重要的。这确保了未来负责项目的团队成员可以在已建立的框架内开展工作。

DevOps 原则应贯穿于产品生命周期的各个阶段，从开发到维护。这些原则考虑到了生产过程中的每一个步骤，带来了从价值流的开始到结束的文化转变。当公司实施 DevOps 时，它会在整个公司内产生波动效应，因为这是一种思维、行动和存在的方式，必须渗透到每个文化层级。这涉及到打破信息孤岛，营造一种合作氛围，这种氛围远远超出了传统组织中典型的工作环境。诚然，转向 DevOps 可能具有挑战性。为了成功实现这一转变，培训至关重要，且需要高层管理的强有力支持。

换句话说，DevOps 文化所特有的紧密合作和持续反馈不应仅限于开发、测试和运维部门。否则，业务部门将陷入一种境地，即推动和销售团队无法交付的成果。这就是为什么与其他部门（如会计、营销和销售等）保持联系，并确保他们了解进展是如此重要。为了实现提高效率、降低成本和提升质量的目标，涉及整个生产线至关重要。例如，销售部门无法与产品交付团队隔离开展合同工作，因为产品交付团队可能在不知情的情况下生产缺乏需求或背景的功能性软件增量。公司内所有利益相关者必须具备共同的视角和深入的意识，以便协调客户需求与当前的交付能力。

需要强调的是，仅仅设立如DevOps 工程师和DevOps 主管等职位，并开发 DevOps 培训与认证计划，并不足以提供足够的知识或经验。DevOps 的概念可以理解为一种文化范式，而不仅仅是存在着一些孤立的个人或团队从事工具开发或在各自领域进行协作。这意味着组织内的所有个人都共同参与统一的 DevOps 方法论的采用和实施。DevOps 哲学要求组织中的每个人都按照其原则和指导方针行事。

具备资质的 DevOps 教练的支持对于将公司转型为 DevOps 导向的组织至关重要。这一转型通过采用包括系统思维在内的全面战略来实现，并优先考虑客户对高质量产品和服务的需求。

现在，你已经考虑了 DevOps 发布管理如何将业务单元纳入开发过程中，让我们稍作调整，讨论一下DevOps 的三种方法，这完全是关于发现更有效的方式，以更快的速度为公司增加价值。

DevOps 的三种方法

DevOps 的三种方法，来源于Gene Kim的书籍《DevOps 手册》，包括三个基本概念，阐述了指导组织有效拥抱 DevOps 文化并实施必要变革的原则、哲学、流程、程序、实践和规范性措施。如果你的组织刚刚接触 DevOps，DevOps 的三种方法是一个很好的起点，因为它们是哲学性的而非技术性的。

第一种方法 – 流程/系统思维

注意力集中在整个系统的性能上，而非某个特定工作领域或部门的表现。这可以是一个大部门，如开发或 IT 运维，也可以是一个小的贡献者，如站点可靠性工程师或软件开发人员。这里特别强调了由信息技术实现的各种收入来源。值得注意的是，工作需求的创建标志着一个新任务的开始——例如，由业务或 IT 部门产生的任务，之后会进入开发阶段，并为特定的 IT 运维环境量身定制。在这一点上，客户将以服务的形式获得价值，这标志着价值交付过程的一个迭代的结束。

如果正确遵循第一条路径，可以确保缺陷不会传递到生产的后续阶段，局部优化不会导致公司范围的停机，流程将不断改进，并且系统的全面理解将持续追求。已经开始但尚未完成的工作量被称为在制品 (WIP)。如果 WIP 很多，这表明您在进行多任务处理，这几乎总会减慢工作的流程。您应该减少批次大小以限制 WIP。

第一条实践包括以下内容：

• 持续集成

• 持续交付

• 持续部署

• 价值流映射 (VSM)

• 看板

• 约束理论 (TOC)

价值流映射

价值流映射是一种精益管理技术，用于分析现状并设计交付产品或服务的活动序列的未来状态。价值流图是一个图形工具，展示特定过程中的所有关键阶段，并有效地测量每个步骤消耗的时间和量。价值流映射直观地描述了物理资源和数据随着操作序列的推进而移动的过程。

价值流映射的目标是发现并消除或最小化价值流中的“浪费”，从而提高特定价值流的效率。消除浪费的目的是通过建立更有效的流程来提高生产力，从而便于识别浪费和质量问题。

TOC

TOC 是一种管理方法，将任何可控系统视为由于最小数量的约束而无法更多实现其目标的方法。在 TOC 中，始终存在至少一个约束。TOC 采用聚焦过程来发现这些约束，随后重新组织业务的其余方面。TOC 运用广泛使用的短语“链条只有最弱的环节才是强的”。因此，组织和流程容易因“弱”个体或组件的存在而失败或中断，后果可能会损害整体结果。

第二条路径 – 放大反馈循环

DevOps 的第二条路径专注于创建快速反馈循环，使您能够快速构建安全、功能丰富的系统，以此来满足客户的喜爱。无论您是否喜欢，软件的复杂性都是不可避免的。即使是看似微不足道的改动，也可能造成巨大的影响。当我们没有及时反馈时，就会在因果之间造成鸿沟。错误可能被悄悄引入，并且可能要到后来时才被认识到，这时候需要的时间和资源来修复这些错误已经增加。

虽然看起来有些矛盾，但让更多人关注一个问题并不总能带来更好的解决方案。当我们将决策过程远离工作执行地时，审批流程的效率会降低。实施第二种方法的结果包括意识到并响应内外部消费者的需求，减少所有反馈环节的长度，同时增强其影响力，并在需要的地方整合知识。

以下实践包含在第二种方法中：

• 自动化测试

• 生产变更的同行评审

• 监控和 通知实践

• “一目了然”仪表盘和 状态更新

• 生产日志

• 过程度量

• 事后分析

• 共享 值班轮换

• 变更、事件、问题和 知识管理

第三种方法——持续实验和学习的文化

第三种方法的核心理念是建立一种文化，鼓励两条 distinct 原则。第一是持续的实验、采取经过深思熟虑的风险，并从这些经历中获得知识。第二是认识到，唯有通过实践和有意义的重复，才能实现精通，这两者同样必要。

在缺乏信任的工作环境中，事件往往伴随着一种反复出现的指责和愧疚模式。自然，这会妨碍个人和整个组织获取知识和技能。对错误的惩罚威胁成为个体保持在熟悉、舒适环境中的动力。这种环境通常被称为舒适区，其特点是通过避免压力来减少遇到挑战或复杂情况的可能性。在追求知识和理解的过程中，个体通常被建议避免进行实验、探索新概念或提出推测性问题。在这种背景下，个人通常会选择隐藏失败，而不是承担责任，以避免承认错误。因此，在当今社会，个体通常表现出较少的倾向去表达自己的想法或提出创新的解决方法。创新往往受到个体或群体的抵制，这是一种悲剧。追求进步需要进行实验并接受风险，即使这意味着进入比之前更多的风险领域。我们必须具备足够的技能，以便能够修复因我们突破极限而导致的不稳定问题。

实施第三种方式的结果可以总结为：投入时间改进日常工作，培养奖励团队冒险精神的常规，并通过偶尔在系统中产生缺陷来追求更高的弹性、效率和专业水平。

以下实践包括在第三种方式中：

• 实验 和学习

• 计划-执行-检查-行动（Deming 循环）

• 改进卡塔

改进卡塔

根据丰田卡塔（Toyota Kata），管理是一种系统性的努力，旨在通过有效地协调人员的能力，实现期望的条件。

改进卡塔（Improvement Kata）是一种系统化的方法，用于以富有创意、有意义且有指导的方式，从当前状态过渡到理想状态。该模型分为四个部分：

1. 进行雄心壮志或轨迹的审视。

2. 理解当前状态。

3. 精确定义未来的目标状态。

4. 逐步向理想状态迈进，揭示并解决沿途遇到的任何困难。

改进卡塔与那些旨在预测轨迹并集中于执行的方式不同，它利用在过程中获得的发现。采用改进卡塔的团队在努力实现理想状态的过程中，获取知识并根据获得的见解调整他们的方法。

这三种方式与当代技术关系不大。它们的核心是发现更有效的方式，以更快的速度为公司增加价值。这将我们带回信息与通信技术（ICT）的基础，即态度、行为和文化：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_05_1.jpg

图 5.1：DevOps 的三种方式（图像灵感来自 Gene Kim，《The Three Ways: The Principles Underpinning DevOps》）

前面的插图展示了DevOps 的三种方式。从上到下分别是：流动/系统思维、反馈循环的增强，以及持续实验和学习的文化。

现在你已经了解了让 DevOps 发布管理独特的突出特点，让我们通过讨论 DevOps 发布管理与传统发布管理方法和工作流的对比来结束本章。

传统的发布管理方法与 DevOps 相比如何？

规划大规模发布需要更多的工作量和风险，这是传统方法的常见重点。在较长周期和较少发布的情况下，复杂性往往会迅速增加。在这种环境下，你将面临严格的最后期限和一大堆附加任务。大规模发布可能会很壮观，但它无疑是一种效率低下的生产方式。然而，DevOps 采用了不同的策略；较小的发布更易于管理，因为它们更简单易懂并且便于测试。如果情况没有按计划发展，损失也较小。从本质上讲，DevOps 使得公司能够通过更快速、更轻量的发布方式迅速适应客户需求的变化。

在管理任何形式的开发时，传统方法通常会使用规划和调度系统。开发周期通常涉及许多环节，尤其在使用传统方法时，调度通常是一个特别艰巨的挑战。DevOps 方法论的基础是频繁和增量的软件发布原则，以及专门团队利用自动化技术。这种方法显著提高了调度过程的效率。重点通常会集中在短期规划上，通常是针对接下来的几周。这将使你对团队时间的合理分配有更高的敏感度。此外，专门团队的建立有助于高效协调，消除了将个人分配到不同角色中的需求。

传统方法通常会对新产品版本或升级的预期发布大肆宣传。当企业采用传统方法时，会在单一发布上投入大量的精力和资源，增加了失败的风险。在这种情况下，工程师往往会在主要发布前花费大量时间独立工作，这通常被称为“高压时期”。开发人员为这个发布准备了数周，甚至数月，现如今他们正在进行最后的努力，修复可能出现的任何问题，以确保按时发布。另一方面，DevOps 团队并不会每次发布新版本或升级时都举办盛大的庆祝活动，而是采用更短、更规律的开发周期。由于自上一个开发周期以来所需的工作量较少，因此发布的风险大大降低。自动化测试的使用确保了他们的环境是一致且可靠的。只有当 DevOps 确信过渡将成功时，才会将产品版本推广到下一阶段。值得注意的是，通过完全摆脱发布窗口的概念，DevOps 使得将新功能更快投入生产成为可能。

在过去准备发布时，通常需要多个人参与，收集所有必要的信息和数据，最终生成一份冗长的报告，并呈交给高层管理。在许多情况下，冗长的报告代表着瓶颈，因为读者无法确定哪些信息最为重要，或者这些报告在他们收到时是否仍然具有相关性。相比之下，当在以 DevOps 为中心的团队中进行自动化操作时，您可以迅速汇总新的信息并有效地做出响应。这意味着您不必浪费时间坐下来翻阅多页数据。如果将收集应用程序数据的任务委托给以 DevOps 为导向的团队，您可以确保该团队的每个成员都能更好地了解与当前任务相关的信息和数据。这不仅最小化了获取信息所需的时间，还减少了获得管理层批准的时间。

此外，采用传统方法的组织通常避免承担任何不必要的风险。由于文化围绕着员工尽一切可能避免对公司造成损害，这些员工承受着巨大的压力，确保一切完美无缺。然而，实际上，任何事物都无法达到完美的巅峰。DevOps 培养了一种与传统方法大相径庭的文化。团队接受了早期识别失败的文化，承认挫折的不可避免性。因此，建立了一个强大的框架和系统化的方法，通过持续测试、渐进部署和自动化来促进可控的失败。DevOps 团队接受这样一种观点：失败发生得越早，其后果越小，最终的恢复也越快。

值得注意的是，传统策略采用了按性价比计费的模型，评估在最少财务投入下可以完成多少工作。采用这一策略存在几个风险，最显著的是，在保持相同工作能力的情况下，降低成本是相当棘手的。这也是许多使用传统策略的企业频繁将运营外包的原因。DevOps 极大地扩展了这一效率的概念，提出了“流”的概念，因为新应用的开发时间应该是战略性度量的标准。这促使团队分析周期时间，以发现浪费的领域并估算真正的生产力。这使得开发人员能够专注于那些能为客户带来最大价值的活动。

使用传统方法时，每个个体完成他们分配的工作后，再将其交给价值链中更远的同事。在这种情况下，他们会过于关注按时完成任务，而忽略了确保他们的工作在实际条件下的可用性。当采取这种方法时，质量往往会受到影响，而没有人对此负责。与此相反，DevOps 强调建立一个跨职能的组织，在这个组织中，所有成员共同承担任务成功完成的责任。由于高质量软件的生产是团队的共同目标，所有成员将就什么才算工作完成达成一致。他们不再因细节问题而焦虑，而是受到更大图景的激励。

DocuSign 从敏捷到 DevOps 的转型案例研究

DocuSign 是电子签名和数字交易管理的先驱。很少有创新能够像 DocuSign 在数字化转型时代那样，深刻影响协议的制定、签署和管理方式。DocuSign 的产品管理历史，以消除障碍、发明创造性解决方案，并不断适应客户日益变化的期望为特征。这家创新公司由 Tom Gonser 创立，他为一种彻底改变全球商业实践的解决方案铺平了道路。

在本案例研究中，我们将揭示 DocuSign 如何从一个敏捷型企业转变为一个 DevOps 强大的企业。

DocuSign 的起源

DocuSign 的故事始于 1990 年代末，当时，具有远见的企业家兼熟练的软件工程师 Tom Gonser 识别出了传统协议签署方式中的不足和复杂性。在互联网日益强大的背景下，Gonser 对繁琐的纸质流程感到恼火，并梦想着一种数字化的替代方案，能够彻底改变企业和个人履行及传递协议的方式。

在共同创始人 Court Lorenzini 和 Eric Ranft 以及其他人的帮助下，Tom Gonser 于 2003 年创立了 DocuSign，旨在通过将传统的合同签署方式转变为一种在线流程，来革新这一传统方式，使之更加简化、安全和快速。他们的目标是开发一个系统，使个人和公司能够从全球任何地方进行数字签署，从而摆脱受限于纸质文件和地理限制的束缚。

凭借决心和对互联网颠覆性潜力的坚定信念，Gonser 和他的团队建立了平台技术的基础，利用算法加密和电子签名技术，确保数字合同的合法性和有效性。在成立的短短几年里，DocuSign 凭借其早期的成功和用户友好的界面，迅速在电子签名行业崭露头角。

向 DevOps 转型

DocuSign 自成立以来，一直秉持敏捷开发方法。然而，向 DevOps 流程的转型证明是相当具有挑战性的。考虑到他们的业务性质——处理合同和签名——持续集成和交付带来了显著的挑战。他们的整个业务依赖于交换签名和批准的复杂交易过程，而从软件开发的角度来看，这个过程非常难以测试。如果发生任何错误，比如错误的批准归属，这将对他们的业务构成重大威胁。为了提高现代开发的效率，他们采用了一种被称为应用程序模型（简称mock）的高效策略。具体来说，他们使用了一个针对内部 API 的 mock。这个工具提供了一个模拟的端点并返回模拟响应。通过这种方法，DocuSign 能够将应用程序测试方法与事件管理无缝集成，并通过与真实世界交易高度相似的模拟进行彻底的应用测试。

DocuSign 产品团队遇到的障碍

DevOps 发布管理生命周期中最重要的部分之一是持续集成。这是将新功能和更新的代码添加到并与原始代码库合并的阶段。在这个过程中，我们通过单元测试找出并修复代码中的错误，并适当地更新源代码。让我们来看看 DocuSign 开发团队面临的独特挑战，并发现他们是如何克服这些挑战的：

• 关于合规性和安全性的法规：DocuSign 运营的领域涉及机密文件和法律合同，因此必须应对与不断变化的合规性和安全性要求相关的困难。产品经理负责监督全球立法领域的复杂事务，确保平台遵守不同的行业合规标准、法律框架和语言复杂性，同时维护数据安全。

• 在复杂性面前改善用户体验：数字签署文档是一个至关重要的过程，它提出了一个相当大的挑战——如何在不失去功能性和安全性的情况下简化这一过程。产品管理必须小心权衡，努力在提升客户体验和处理机密文档、验证其合法性之间找到平衡。

• 与集成和互操作性相关的难题：DocuSign 产品管理面临的挑战是实现无缝集成，并与其他公司开发的各种平台和应用程序兼容。这是因为组织使用了大量的数字化解决方案。DocuSign 需要做的最重要的事情之一就是确保能够轻松集成到其用户已经部署的工作流程和系统中。

DocuSign 的开发人员通过创建一个基于事务模拟的定制内部测试框架，成功地在组织内建立了 DevOps 发布管理的原则。这使得团队能够应对一个高度挑战性的任务，即在复杂的应用程序中执行自动化集成测试，该应用程序具有复杂的审批流程、安全的图形界面以及强加密的 API 交易，并且这些都在 CI/CD 流水线中进行。通过这些创新测试策略的成功，DocuSign 能够迅速成熟其商业模式，增加了新的产品线，并保持其作为行业主导的电子签名产品公司的地位。

总结

本章结束于第五章。此时，您已经牢牢掌握了 DevOps 发布管理独特性的含义。你了解了 DevOps 是一种整体实践，在制定解决方案或改进整体系统时，考虑到价值流的每个组件。DevOps 的独特之处在于它将 CI/CD、QA、安全性和反馈整合在一起。通过使用精心设计的自动化流水线和精心挑选的测试与审批流程，DevOps 发布管理与其他发布管理模型相比，具有独特优势。DevOps 理念中至关重要的特点之一是将业务团队融入开发过程。你还探讨了DevOps 的三种方式这一重要概念，这一概念由Gene Kim（《DevOps 手册》的作者）普及。此时，你已经准备好区分传统的发布管理方法和 DevOps 方法。

在下一章中，我们将回顾 CI/CD 的基础知识。今天的发布经理必须精通 CI/CD 流程、DevOps 和自动化部署技术。你需要理解 CI/CD 流水线的运行方式，并能够在早期阶段识别问题，这对于 DevOps 发布管理至关重要。

问题

回答以下问题，以测试你对本章内容的理解：

1. DevOps 的三种方式是什么？

2. Shift-left是什么意思？

3. 什么是紧密反馈回路，为什么它们很重要？

4. 为什么消除孤岛效应或个别团队的孤立工作对于组织的成功至关重要？

5. 什么是 DevSecOps？

6. 为什么像DevOps 工程师和DevOps 总监这样的职位称谓是一个误区？

7. 如何通过使用 DevOps 发布管理来减少对其他团队的依赖？

8. 什么是冲刺期，DevOps 是如何避免它的？

9. DevOps 的主要目标是什么？

10. 拥有一个全面的工具集成平台有什么重要意义？

第六章：理解 CI/CD 基础

持续集成和持续交付（CI/CD）是 DevOps 发布管理的关键策略。它自动化了大多数传统上需要人工干预的步骤，这些步骤通常用于生成新的软件发布或将新代码推向生产环境。CI/CD 包括集成测试、单元测试、回归测试以及构建和部署阶段。基础设施即代码也可以集成到 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 是当今软件行业的生命线，推动着新程序的快速创建和分发。消除集成和交付瓶颈的工具对于任何 CI/CD 流水线的顺利运行至关重要。团队需要统一的一套技术来协作高效地完成项目。源代码控制、测试工具、基础设施修改和监控工具只是可以与这个框架统一的 SDLC 元素中的一部分。

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

什么是 CI/CD 流水线？

CI/CD 流水线简化了将软件或基础设施作为代码进行交付的过程，确保从源代码到生产部署的顺利过渡。可以将其视为代码发布的必要步骤序列。

CI 是持续集成（Continuous Integration）的缩写，而 CD 是持续交付（Continuous Delivery）或持续部署（Continuous Deployment）的缩写。流水线的概念涉及自动化交付工作流的各个阶段，包括构建、测试、交付和部署。通过自动化和控制交付过程的每个阶段，CI/CD 流水线的所有优点得以释放。这有助于最小化人为错误，并确保每次发布的一致性。

CI/CD 流水线通常作为代码进行配置，因此广泛被称为流水线即代码。为了方便流水线的运行，通常会使用 CI 服务器及其相应的构建代理。根据所使用的产品，构建代理可能被称为runner。通常，构建代理以虚拟机的形式出现，可以自托管、完全定制，并且需要定期维护。另一方面，如果你使用的是商业 SaaS 产品，你可以使用 SaaS 提供商提供的 CI 服务器和构建代理，但在定制化以及添加软件或插件时可能会有一些限制。

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

架构良好的 CI/CD 流水线基础设施应该设计为接受参数，能够在任意环境中产生可重复的结果。它们也具有适应性，考虑到存在消费者需求但现有的 DevOps 解决方案未能满足的场景。在这种情况下，可以快速识别解决方案，进行分析、开发，并在相对较短的时间内将其部署到应用环境中——所有这些都不会中断应用的正常开发流程。

此外，CI/CD 还允许即便是微小的变更也能迅速部署到最终产品中，从而加快了对用户请求的响应时间。它不仅解决了用户的关切，还让他们了解设计和创建过程。用户会注意到随着更新的推出，产品在不断改进，解决了 bug 并添加了新功能。与更传统的方法（如瀑布模型）相比，后者直到开发过程的最后阶段才会让用户参与，DevOps 发布管理促进了整个产品生命周期中的持续反馈和完善。

不同的项目在 CI/CD 管道中需要不同的复杂度和步骤数。一个潜在的管道可能采用多阶段部署方法，其中软件作为容器分发到一个跨多个云环境的 Kubernetes 集群中。相反，另一个管道可能采用更直接的方法，涉及构建、测试和部署一个作为 .jar 文件运行在虚拟机上的应用，并通过代理服务器进行访问。在这个示例中，这两个管道的目标都是自动化软件交付过程。

本质上，建立一个架构良好的 CI/CD 管道基础设施对于充分发挥 DevOps 发布管理所带来的所有好处至关重要。在下一部分中，我们将深入探讨持续集成的话题。内容将包括 CI 的含义、如何为你的组织选择合适的 CI 工具、示例管道语法以及功能比较。

什么是持续集成（CI）？

现代软件开发如果没有持续集成（CI）是无法实现的。现代软件的创建通常涉及来自不同地区的众多开发人员的协作，每个开发者专注于产品的某个特定组件、功能或方面。为了将一个完整的产品发布出来，必须将所有这些代码更改合并起来。然而，手动合并所有这些更改极其不实际，而且是一项痛苦的工作，当多个开发人员并行工作时，代码更改之间不可避免地会发生冲突。然而，持续集成鼓励开发人员持续将代码推送到同一个版本控制系统（VCS），提供了一种解决这一问题的绝妙协同效应。通过使用 CI，你可以持续提交、构建和测试团队的代码，这对于 DevOps 发布经理来说是一项至关重要的策略。如果你的团队经常测试新代码，他们将在缺陷深入软件之前就能够捕获并修复这些缺陷。

虽然对于 CI 可以使用哪些工具没有硬性要求，但许多团队倾向于使用如 Jenkins、GitLab CI 或 GitHub Actions 等持续集成服务器。随着新代码更改的提交，持续集成服务器会监督一切，并充当裁判。每当开发者在代码库中提交工作时，CI 服务器会自动运行一系列测试并记录结果。做出更改的开发者通常会在提交后不久收到一封包含测试结果的电子邮件。这非常关键，因为它使得开发者能够在最短时间内解决潜在问题。

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

增加提交频率的另一个好处是，个别贡献者可以在早期阶段主动发现并解决合并冲突，减少其发生的频率，甚至完全避免它们。此外，集成更小的工作增量是避免一次性提交大量更改并遇到神秘错误的有效方式；开发者将会产出更少的代码，合并的行数也更少。这使得识别和解决代码中的 bug 和缺陷变得更加高效，将所需时间从几个小时减少到几分钟。

为你的操作选择合适的 CI 工具

在为团队的操作选择合适的 CI/CD 工具时，你有很多选择。评估你独特的需求和偏好至关重要，因为每个工具都有其优缺点，这可能会影响你的成功。无论你偏好开源选项、人工智能功能、本地解决方案、峰值可扩展性，还是广泛的定制功能，你都可以找到适合你需求的工具。

在为你的团队评估各种 CI/CD 工具时，你应该考虑以下核心因素，以便做出最终选择：

• 本地部署与云部署：评估工具是否提供基于云的和/或本地（托管）解决方案，并选择最适合你项目需求的选项。

• 开源与闭源：考虑 CI/CD 工具与开源项目的兼容性，并评估它与项目目标的契合度。

• 测试集成：建议选择一个具有用户友好界面并且配置容易理解的 CI/CD 工具，以减少与设置相关的困难。

• 设置和配置的简易性：你应该选择一个具有用户友好界面且配置易于理解的 CI/CD 工具，以减少设置过程中的复杂性。

• 构建环境兼容性：考虑工具与项目环境和编程语言的兼容性，以简化集成过程。

• 学习曲线：建议考虑开发人员在设置和配置构建及部署工作流时可能面临的学习曲线，以便更好地支持他们。

• 付费计划功能：为了应对项目的增长，建议检查付费计划（如果有）中现有和新提供的功能，包括分配的每日构建次数、运行时分钟数、用户数量以及私有仓库数量等。

• 版本控制系统兼容性：确保你验证 CI/CD 工具是否能够与您首选的版本控制系统或源代码管理平台顺利集成，从而实现高效的源代码管理和交付。

让我们深入了解三款行业领先的 CI/CD 工具，帮助你评估哪一款最适合你的企业。首先，Jenkins 是一个非常著名的 CI 服务器，已经存在了很长时间，提供了许多插件，具有一些新竞争者所没有的功能。另一个与 GitHub 仓库优雅集成的强大工具是 GitLab CI。别忘了 GitHub Actions，它提供了一个简单易懂的工作流程。

Jenkins

Jenkins 是一个知名且高度可定制的开源 CI/CD 工具，几乎可以自动化所有工作。Jenkins 使用 Java 编程语言开发，并且是开源的，采用 MIT 许可证发布。该软件提供了一个全面的功能范围，可以简化多个任务，包括构建、测试、部署、集成和发布软件。Jenkins Server（主服务器）软件兼容 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 注册表：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_06_01.jpg

图 6.1：示例 Jenkinsfile – 配置构建 Docker 镜像的管道

GitLab CI

在所有可用的 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 文件中定义）需要执行，并根据需要跳过某些任务或将它们排队。然后，这些任务将按正确的顺序分配给可用的 Runner。

前述图中所示的 GitLab 架构包括以下组件：

• 提交（Commit）：提交是对文件或代码所做更改的记录，就像你在 GitHub 仓库中看到的那样。

• 任务（Jobs）：任务是 GitLab 管道需要执行的单独任务，例如部署应用程序。每个任务都有一个名称，并包含一个脚本。每个脚本按顺序执行，确保每个任务在进行下一个任务之前都已经完成。

• 阶段（Stages）：阶段用于清晰地区分不同的任务，标志着管道在每个步骤中的进展。这有助于明确任务的执行顺序。例如，阶段可以包括测试、构建和部署。

• 管道（Pipeline）：管道是一组完整的阶段，每个阶段由一个或多个任务组成。GitLab 提供了多种管道选项，如基础管道、合并管道、父子管道和多项目管道。

• Runner：Runner 是负责执行 CI/CD 管道的活动组件。你可以选择在本地设置自托管的 GitLab Runner，或者使用 GitLab 提供的运行器，作为其 SaaS 产品的一部分，托管在 GitLab.com 上。

• GitLab 服务器：GitLab 服务器负责托管和管理你的管道配置。你可以在本地设置自己的 GitLab 服务器实例，也可以使用托管在 GitLab.com 上的 SaaS 版本。

GitLab CI 语法示例

让我们通过一个 GitLab CI/CD 管道的示例，来实际了解它的语法以及如何进行配置！在 .gitlab-ci.yml 文件中，构建一个 Docker 容器镜像，并将生成的工件发布到指定的 Docker Registry：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_06_02.jpg

图 6.2：示例 GitLab gitlab-ci.yml 文件 – 配置用于构建 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 文件。

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

• 事件：事件是启动工作流的定义触发器。开发者可以配置它们以搜索一个或多个触发器，然后根据需要进行调整。此外，事件还可以配置为在 GitHub 上指定代码库中的指定代码分支上执行。

• 作业：作业由一系列在单个运行器上执行的顺序任务组成。每个任务在自己的虚拟机（VM）中运行，并与其他任务并发执行，除非另有声明。

• 步骤：步骤是一个独立的操作，用于在作业中执行命令。这些步骤可以是动作或 shell 命令。作业中的每个步骤都在同一个运行器上执行。

• 动作：动作指的是在运行器上执行的命令，它是 GitHub Actions 的基本组成部分，GitHub Actions 也因此得名。

• 运行器：运行器作为 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 的Workflow文件中，正在构建一个 Docker 容器镜像，并将生成的工件发布到指定的 Docker 注册表：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_06_03.jpg

图 6.3：GitHub Actions 工作流示例——配置为构建 Docker 镜像的管道

现在我们已经对这三种工具的语法差异有了基本的了解，接下来让我们对这三种 CI 工具的功能进行比较。

三种 CI 工具的并排功能对比

以下表格提供了 Jenkins、GitLab CI/CD 和 GitHub Actions 这三种行业领先 CI 工具的功能和优点的并排对比。所提供的信息旨在帮助你根据自己的独特需求和偏好评估哪种工具最适合你的操作。

特性	Jenkins	GitLab CI/CD	GitHub Actions
本地部署（自托管）	是	是	仅限 Runner
基于云	否	是	是
开源	是	是	否
闭源	否	是	是
测试集成	是	是	是
安装和配置简易性	困难	中等	容易
构建环境兼容性	Linux, Windows, macOS, Unix	Linux, Windows, macOS	Cloud SaaS
语言支持	任何现代语言	C, C++, C#, Go, Java, JavaScript, PHP, Python, Ruby, Scala, TypeScript 等	C, C++, C#, Java, JavaScript, PHP, Python, Ruby, Scala, TypeScript
学习曲线	困难	中等	容易
付费计划功能	否	是	是
VCS 兼容性	GitMercurial (hg)Subversion (svn)Perforce (p4)ClearCaseMicrosoft TFS	Git	Git

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

代码集成、自动化构建和集成测试是持续集成的三大支柱。持续集成过程的最终目标是生成一个可部署的工件。这标志着我们对持续集成及其工具的探讨结束。在下一部分，我们将讨论持续集成的对立面——持续交付。

什么是持续交付（CD）？

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

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

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

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

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

在技术领域，基础设施一词通常与物理组件相关，如机架服务器、网络系统和数据中心。然而，随着云计算的普及，基础设施已经超越了其物理限制，转变为可以快速创建、修改和废弃的虚拟服务和环境。在这个新时代，如何高效、可靠地管理和提供这些动态资源，已经成为一个重大挑战。这时，基础设施即代码（IaC）概念变得尤为重要。IaC 工具已成为解决这些挑战的关键，通过允许通过代码管理基础设施，而不是依赖手动过程。这种方法简化了构建和维护虚拟 IT 基础设施的过程，提高了一致性，最小化了错误风险，并实现了轻松的自动化和可扩展性。

正因为如此，理解幂等性概念在 IaC 中的重要性。在执行 IaC 部署时，它确保目标环境的配置始终一致，无论其初始状态如何。也就是说，幂等性可以通过两种方法实现：自动配置当前目标，或者丢弃它并从头开始创建一个新的目标环境。

幂等性

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

值得注意的是，基础设施即代码（IaC）已成为解决配置漂移问题的主要解决方案，无论是在发布流水线还是虚拟化部署环境中。至关重要的是，如果没有 IaC，团队将需要手动分别管理环境和部署配置。以这种方式操作时，随着时间的推移，每个环境不可避免地会发展出自己独特的配置，而这些配置无法自动复制。因此，由于不同环境（如开发、质量保证、预发布和生产环境）之间的不一致，可能会导致部署问题。由于依赖手动过程，基础设施管理和维护可能会变得具有挑战性，容易出错，并且难以监控。

配置漂移

信息技术系统配置随时间逐渐变化的现象被称为配置漂移。漂移通常是在没有适当文档或批准的情况下对软件、硬件或操作系统进行修改时无意发生的。它可能会影响系统某一部分或整个系统的安全性和效率。应用程序故障、停机时间、开发周期延长、IT 服务请求激增、安全漏洞、审计罚款、合规性失败等，都是配置漂移的直接后果。

相反，基础设施即代码（IaC）利用了 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 的工作流极其简单，只有三个步骤就能有效管理任何类型的基础设施：写、计划、应用。Terraform 的三步流程是管理任何类型基础设施的最简单工作流之一。它允许用户根据自己的具体需求和实施风格定制工作流。为了说明 Terraform 的工作原理，让我们看看一个示例 Terraform 计划，该计划可用于在 AWS 中创建一个 EC2 实例：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_06_04.jpg

图 6.4: 示例 Terraform 计划 - 配置以提供 AWS EC2 实例

Pulumi

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

用流行编程语言编写的 Pulumi 程序概述了云基础设施的组成。添加新基础设施时，您只需将资源对象分配为符合基础设施所需状态的属性。这些属性可以用来管理资源之间的依赖关系，并且如果需要，能够导出到堆栈之外。

Pulumi 平台由多个组件组成：

• Pulumi 软件开发工具包（SDK）：它为每种资源类型提供绑定，可以由提供商管理。该资源为用户提供了必要的工具和库，以便有效地定义和管理跨不同提供商和平台的云资源。

• 命令行界面（CLI）：它允许您部署云应用程序和基础设施的更新。它还记录了团队的更新，包括贡献者和时间戳。

• 部署引擎：部署引擎计算出将您的基础设施当前状态与程序指定的目标状态对齐所需的操作。

程序存储在项目中，项目是一个包含程序源代码及执行指令的目录。完成程序后，你可以从项目目录使用 Pulumi CLI 执行Pulumi up命令。该命令允许你创建一个独立且可定制的程序实例，称为堆栈。堆栈作为用于测试和实现应用程序更新的各种部署环境。例如，你可以创建并测试独立的开发、暂存和生产堆栈。

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

最后，服务器的 IP 地址和 DNS 名称作为堆栈输出导出，便于通过 CLI 命令或其他堆栈轻松访问。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_06_05.jpg

图 6.5：示例 Pulumi 代码 – 配置为提供 AWS EC2 实例

Ansible

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

与其类别中的其他工具（如 Chef 或 Puppet）不同，Ansible 不需要在远程节点上安装任何专用软件（代理）。控制机器配置了 Ansible 软件，使其能够通过标准 SSH 协议与节点通信，Python 被用于执行远程指令。

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

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

为了说明 Ansible 如何工作，让我们看一个示例 Ansible 剧本，它可以用于在 AWS 中创建一个 EC2 实例：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_06_06.jpg

图 6.6：示例 Ansible 剧本 – 配置为提供 AWS EC2 实例

Puppet

Puppet 是一个配置管理工具，利用其自身的声明性语言来描述基础设施的状态。Puppet 的语言旨在高效地处理 IT 基础设施的每个生命周期阶段，包括任务如供应、修补、配置和操作系统与应用组件的管理，适用于数据中心和云基础设施。

Puppet 专门设计用于处理类 Unix 系统和 Microsoft Windows 系统的配置。为此，用户分配系统资源及其状态，使用 Puppet 的声明性语言或 Ruby 领域特定语言 (DSL)。通过这种方式，基础设施配置存储在被称为 Puppet 清单的配置文件中。执行时，Puppet 工具会将 Puppet 清单编译成一个特定于系统的目录，其中包含资源及其依赖项。然后可以将该目录应用到目标系统，并将 Puppet 执行的结果报告给用户。

Puppet 通常遵循客户端-服务器架构。在这种情况下，客户端被称为代理（agent），而服务器通常被称为主控（master）。此外，它也可以作为一个独立的应用程序，从命令行执行，方便进行测试和基本配置。Puppet Server 通常安装在多台服务器上，而 Puppet Agent 则安装在所有需要管理的机器上。通过这种方式，Puppet 代理与服务器通信以获取配置指令，然后进行部署。代理会在目标系统上实现配置，并及时向服务器发送详细的状态报告。值得注意的是，机器能够作为守护进程（daemon）运行 Puppet 代理，这可以定期安排为 Cron 作业运行，或者根据需要手动执行。

为了说明 Puppet 如何工作，让我们看一个示例 Puppet 清单，它可以用于在 AWS 中创建一个 EC2 实例：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_06_07.jpg

图 6.7：示例 Ansible 剧本 – 配置为提供 AWS EC2 实例

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

尽管 IaC 和 CaC 之间存在相似之处，但它们也有显著的差异。如前所述，IaC 主要用于部署虚拟基础设施，包括服务器实例、存储设备和网络组件，以及任何额外的资源和权限。相比之下，作为代码的配置工具则在此基础上跟进，配置和定制操作系统、应用程序配置以及在使用 IaC 工具生成基础设施后监控设备。这项活动用于自动创建精确符合客户或业务特定需求和目标的计算系统。这两种自动化工具各具独特优势，适合在特定用例中使用，或者一起使用。

为了帮助你理解其差异，这里有一个类比。基础设施即代码可以看作是使用工具来建造一座办公大楼，而配置即代码则是一套用于为办公大楼配备设备和资源的工具，这些设备和资源是企业完成实际工作的必需品。

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

持续交付管道

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

持续交付管道有五个主要阶段：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_06_08.jpg

图 6.8：持续交付的五个常见阶段

该图展示了持续交付策略中最常见的五个阶段：提交、测试、构建、预发布和部署。正如你所看到的，这个周期被设计得尽可能短，从新的代码更改提交到版本控制，再到它在生产环境中部署的时间间隔最短。除此之外，还包含了多个验证步骤，以确保最高的质量。这包括构建代码的能力，这本身就可以视为一种测试形式。

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

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

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

通过持续交付，减少了手动部署新代码的需求，从而节省了时间和资源。首先，编写代码，然后自动测试，接着批准，最后推送到一个仓库，其他工程师可以访问。当代码完成后，运维团队可以迅速获取并轻松地通过自助功能将其部署到生产环境。

该图展示了持续交付与持续部署流程的区别：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_06_09.jpg

图 6.9：持续交付与持续部署

正如你所看到的，有一个决定性特征区分了这两者：部署到生产环境。在持续交付中，必须在允许新的代码更改部署到生产环境之前执行人工批准步骤。而在持续部署中，自动化测试承担了这个角色，因此不需要人工干预。

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

连续部署比持续交付更难实施，因为它在将授权的软件产品部署到生产环境时完全消除了任何人工干预的需求。这意味着，为了实现真正的连续部署，您的自动化测试必须丰富、可互操作和可扩展。

GitOps 如何与持续交付结合

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

GitOps 是 DevOps 更广泛领域内的一个专业领域，其核心是利用 Git 仓库来有效管理基础设施状态和应用部署。GitOps 与 DevOps 的一个重要区别在于，Git 仓库在应用和基础设施部署状态的管理中充当单一权威数据源。因此，Git 仓库类似于账本或者说类似于区块链的概念。

另一个关键要理解的事情是，GitOps 在其主要实施方法中严重依赖拉取式部署。在传统的 DevOps 方法中，连续集成和连续交付流水线是由外部事件触发的，例如当新代码推送到应用程序仓库时。与此不同，GitOps 通过拉取式策略保持应用程序的实时性，通过将当前部署的应用程序状态与版本控制仓库中声明的理想应用程序部署状态进行比较。如果检测到两者之间的任何差异，GitOps 操作者将更新实时基础设施，使其与指定仓库中声明的配置相匹配。

聪明地，拉取式部署使得在出现问题时轻松将不稳定的软件部署回滚到已知的最后稳定版本成为可能。此外，拉取式技术是声明性的，使得实施蓝/绿和金丝雀部署等高级部署策略变得轻松。

蓝/绿部署

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

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

金丝雀部署

金丝雀部署指的是一种逐步和受控的应用发布策略，其中流量被分配给现有版本和新版本。该方法首先将新版本引入到一小部分用户中，然后再将其部署到整个用户群体中。通过采用这种方法，可以在广泛分发给消费者之前确定更新版本应用程序的可靠性。

什么是持续测试？

到目前为止，你应该已经牢牢掌握了自动化测试的重要性，至少基于对该主题的多次提及。强调自动化测试对 DevOps 发布管理的重要性是不容忽视的。

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

然而，在组织中实施持续测试并不是一项简单的任务，因为你必须制定一个测试策略，以确保变更能够顺利推进，而不会触发任何误报。就像持续部署一样，实施持续测试比听起来要复杂得多，因为它们是相辅相成的。传统上，软件测试是在代码编写完成后首次进行，然后交给质量保证团队独立测试。当在代码中发现错误时，错误会被返还给开发人员以进行修正。在开发周期较慢时，这种测试模型在一定程度上是可行的。然而，在如今快速发展的环境中，这种模式不仅充满挑战、繁琐，而且容易导致中断和人为错误。相反，当今的组织要求快速交付高质量的产品，因为这是客户在竞争激烈的数字市场中所期待的。如果资源允许妥善实施，那么在以 DevOps 为中心的组织中，没有比持续测试更好的方式了。

持续进行测试的价值就在于此。如果在将代码添加到仓库后立即进行测试，错误可以在更多工作进行之前被发现并修复。这样就不需要在未来做出针对 bug 修复的代码修改，因为这些错误的存在本可以在一开始就避免。在我们这个现代化时代，开发者甚至可以从直接安装到本地集成开发环境（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 计划。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_06_10.jpg

图 6.10：Capital One 的三阶段 DevOps 转型

创建跨职能团队

Capital One 开始通过为公司内两个旧有应用程序分配专门且多才多艺的 SWAT 团队来实施 DevOps。这些跨职能团队慷慨地实施了配置管理和关键功能的自动化，并优化了这两个应用程序的工作流。随后，每个团队继续负责其指定应用程序的交付过程。这个策略在 Capital One 的另外四个应用程序中得到了重复实施，之后管理层鼓励公司其他开发团队也采纳这些新发现的最佳实践。

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

利用微服务架构

与其他在互联网泡沫时代存在的公司一样，Capital One 在架构技术栈时使用了单体设计。随着时间的推移，他们的项目开始扩展，因此必须考虑未来的需求。结果，该银行投入了更多资源，深入研究了微服务架构及其在公司中的适用性。

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

Capital One 的团队在其管道交付中实现了不可变的阶段：

• 实施有效的源代码控制管理

• 实施安全的应用程序和二进制数据存储地点

• 实施强健的特权访问管理和授权

• 确保定期执行质量和安全检查

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

• 非对称的服务部署

• 无限可扩展的应用程序

• 高可用性

• 职责和责任的逻辑分离

• 改进的错误处理

在 AWS 上构建按需基础设施

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

Capital One 的开发团队通过以下亚马逊网络服务工具获得了宝贵的用户洞察，并能够更快地做出响应：

• 虚拟私有 云（VPC）

• 简单存储 服务（S3）

• 弹性计算 云（EC2）

• 关系型数据库 服务（RDS）

使用 Jenkins 自动化交付管道

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

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

Jenkins 使 Capital One 精简了软件交付流程，提高了运营稳定性，并为开发人员提供了更好的整体体验。

Capitol One 的 CI/CD 管道治理

Capital One 旨在实现一种无畏发布的文化，以促进创造性思维。然而，这也需要采取一种思维方式，要求个人对他们所做的决策和在软件交付中的角色负责。著名战略家和 DevOps 传播者 Tapabrata “Topo” Pal 及其团队在 Capital One 实施了清洁室开发的概念。他们将这一概念修改为适用于软件开发生命周期，以拥抱一种勇气和责任感的文化。

清洁室

“清洁室”一词指的是一个经过设计的空间，它能将空气中的颗粒物浓度保持在极低水平。它具有活跃的净化功能、良好的隔离性和优秀的污染控制。这类房间通常是所有纳米级过程（包括半导体制造）和科学研究所必需的。为了保护室内处理的材料，灰尘和其他空气中的有机物，如蒸发的颗粒，必须远离清洁室。

一套明确的指南，用于在发布前保证代码质量，可以视为公司虚拟开发清洁室的标准。这些政策涵盖了诸如定位和注册每个产品管道、审核和检查每个版本的代码、限制对生产服务器的访问等程序。简单来说，清洁室方法强调的是预防缺陷，而不是消除缺陷。最终，Capital One 利用清洁室模型来检测和解决不同产品管道中的问题，从一开始就确保了质量。毕竟，一分预防胜过一磅治疗。

以下插图完整描述了 Capital One 的“清洁室”DevOps 发布管理方法。这个过程从开发阶段开始，在该阶段，应用程序代码保存在版本控制管理中。接着，采取一系列安全措施，如限制对二进制文件的访问，并包括静态代码分析。本节的重点是确保编写的代码在完整性、机密性和可用性方面得到妥善存储。

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

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

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_06_11.jpg

图 6.11：Capital One 的清洁室发布方法

实施混沌工程

即使有多个访问控制和保护措施，软件部署有时仍会变得混乱。云故障可能是不可预测且无法避免的，在某些情况下，如可用区停机，可能会带来风险。有人可能会说，持续交付也带来了持续混乱的可能性。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 为中心的软件组织的首要质量保证策略。

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

问题

回答以下问题，以测试你对本章的知识掌握情况：

1. CI/CD 管道是否可以用于自动化除了发布和部署软件所需活动以外的其他任务？

2. 为什么软件开发团队需要一套统一的技术工具，以达到最高生产力？

3. 增加提交频率的好处是什么？

4. 什么是持续集成服务器，它的功能是什么？

5. 持续交付与持续部署的主要区别是什么？

6. 持续交付管道的五个主要阶段是什么？

7. 什么是 GitOps，它与 DevOps 有何不同？

8. 自动化测试和持续测试有什么区别？

9. 软件开发人员在代码提交之前，检测和修复代码中的 bug 或缺陷的最佳方法是什么？

10. 金丝雀部署与持续测试有什么共同点？

第七章：面向技术发布经理的实用管道

本章与本书的其他章节略有不同。在本章中，您将学习如何构建一个包含简单 Web 应用程序的 Docker 镜像，该镜像使用 GitHub Actions 部署到 AWS ECS。

本次练习涉及的测试包括HTML 扫描、NodeJS 扫描、凭证扫描和依赖扫描。除了静态应用程序安全测试（SAST）外，管道还使用了 OWASP ZAProxy，这是一个动态应用程序安全扫描工具。通过这些质量检查，确保正确实现文档对象模型（DOM），检查代码中的已知漏洞，并主动检查已部署应用程序在云端的安全漏洞。

完成此任务的策略将分为两部分。首先，您将学习如何配置所需的 ECS 基础设施。其次，您将学习如何配置 GitHub Actions 工作流，以便测试、构建并将 Docker 容器部署到 ECS。通过这两个练习，您将成功掌握当代应用程序交付中使用的基本概念。

本章将涵盖以下主要主题：

• 审查管道代码

• 配置 AWS 基础设施

• 配置 GitHub Actions 工作流

在进行本章包含的练习之前，您需要先审查 GitHub Actions 工作流文件。在最底层了解 CI/CD 管道是您完全理解其执行的所有操作的唯一途径。了解这些细节确保您能获得必要的上下文，以保证软件的安全和快速发布。这也使您做好准备，能够向领导和相关方清晰地传达每一步操作。仅仅从高层次理解管道如何运行，对 DevOps 发布经理来说是不够的。

您可以在github.com/PacktPublishing/Embracing-DevOps-Release-Management/blob/main/.github/workflows/aws.yml找到完整的 GitHub Actions 工作流文件。

以下是本章练习所用的 GitHub Actions 工作流脚本的简化版本：

...    - name: Build, tag, and push image to Amazon ECR
      id: build-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        IMAGE_TAG: ${{ github.sha }}
      run: |
        # Build a docker container and
        # push it to ECR so that it can
        # be deployed to ECS.
        docker build . -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG -f chapter07/Dockerfile
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT
    - name: Fill in the new image ID in the Amazon ECS task definition
      id: task-def
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: ${{ env.ECS_TASK_DEFINITION }}
        container-name: ${{ env.CONTAINER_NAME }}
        image: ${{ steps.build-image.outputs.image }}
    - name: Deploy Amazon ECS task definition
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: ${{ steps.task-def.outputs.task-definition }}
        service: ${{ env.ECS_SERVICE }}
        cluster: ${{ env.ECS_CLUSTER }}
        wait-for-service-stability: true
...

现在，您已经有机会查看此 GitHub Actions 工作流中的管道代码，并且对每个步骤及其执行的工作有了基本的了解。接下来，让我们开始实现一个完整 CI/CD 管道所需的第一组活动：配置云基础设施。

配置 AWS 基础设施

为了确保尽可能广泛的受众能够完成本练习，我们将使用 ClickOps 在 AWS 中配置所有必要的基础设施。ClickOps 是指使用提供商的原生 Web 控制台手动配置云资源的过程。顾名思义，这一过程需要通过键盘和鼠标输入所有必要的信息。ClickOps 被广泛认为是 DevOps 世界中的一种反模式，主要因为它比使用 基础设施即代码（IaC）更低效、更容易出错。然而，对于那些不知道如何编写脚本、写代码或使用命令行界面的人来说，它非常有用。

前提条件

为了完成本指南的这一部分，您需要确保以下前提条件得到满足：

• 您必须拥有一个有效且状态良好的 AWS 账户（console.aws.amazon.com/console/home?nc2=h_ct&src=header-signin）。

重要

请注意，通过遵循本指南，您将在操作过程中为所创建的资源支付 Amazon Web Services（AWS）的费用。直到所有资源被终止前，您将继续被收费。

强烈建议在完成本指南后终止所有这些资源，以避免未来继续被收费。

• 您的 AWS IAM 用户拥有有效的访问密钥。有关如何创建 IAM 访问密钥的更多信息，请参阅 管理 IAM 用户的访问密钥：docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html。

• 您的 AWS IAM 用户必须被授予必要的角色，以便能够在 AWS 中配置 ECS、ECR 和 VPC 资源。有关更多信息，请参阅 基于身份的 AWS 策略示例 ECS：docs.aws.amazon.com/AmazonECS/latest/developerguide/security_iam_id-based-policy-examples.html#IAM_cluster_policies。

• AmazonEC2ContainerRegistryFullAccess、AmazonEC2FullAccess 和 AmazonECS_FullAccess 策略。除了成为 AWS 账户中的管理员用户外，这些就是您在跟随本指南时所需要的全部权限：

注意

授予完全访问权限（如我们在这里所做的）由于安全原因并不是最佳实践。我们仅在本次演示中做出例外，以便让不熟悉 IAM 的初学者更容易通过此过程。因此，强烈建议在完成本次操作后，移除 IAM 用户的这些权限。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_01.jpg

图 7.1：您的 AWS 用户所需 IAM 策略示例

上述截图显示了完成此练习所需的 AWS IAM 策略（前面提到过）。您必须将这些策略添加到所选的 IAM 用户。可以通过 AWS 控制台中的添加权限菜单来实现此操作。有关此过程的帮助，请查阅有关身份管理策略的官方 AWS 文档：

• docs.aws.amazon.com/AmazonECS/latest/developerguide/security_iam_id-based-policy-examples.html

• docs.aws.amazon.com/AmazonECS/latest/developerguide/security_iam_id-based-policy-examples.html#IAM_cluster_policies

步骤 1 – 分叉仓库

按照以下步骤分叉仓库：

1. 点击分叉框中的下拉箭头并选择创建新分叉。或者，访问github.com/PacktPublishing/Embracing-DevOps-Release-Management/fork：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_02.jpg

图 7.2：在 GitHub 中分叉仓库

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_03.jpg

图 7.3：确认此仓库的新分叉

1. 在分叉仓库页面上，指定所有者值并选择创建分叉。

步骤 2 – 创建默认 VPC

在继续之前，请注意，在同一地区内创建多个默认 VPC 是不可能的。如果您不小心删除了默认 VPC，则可以创建一个新的。然而，重要的是要注意，无法恢复先前删除的默认 VPC，也无法将当前非默认 VPC 指定为默认 VPC。

要通过 AWS 控制台建立默认 VPC，请按照以下步骤操作：

1. 通过访问console.aws.amazon.com/vpc/进入 Amazon VPC 控制台。

2. 从导航窗格中选择您的 VPC：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_04.jpg

图 7.4：创建默认 VPC

1. 选择操作，然后创建默认 VPC。

2. 选择创建默认 VPC选项。请在确认信息后关闭该消息：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_05.jpg

图 7.5：确认您的新默认 VPC

步骤 3 – 在默认安全组中创建 HTTP 规则

每当向安全组添加规则时，它会自动应用到所有与该组关联的资源。

要通过 AWS 控制台建立新的安全组规则，请按照以下步骤操作：

1. 通过访问console.aws.amazon.com/vpc/进入 Amazon VPC 控制台。

2. 从导航窗格中选择安全组：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_06.jpg

图 7.6：访问安全组菜单

1. 选择所需的安全组。

2. 选择操作，然后选择编辑 入站规则：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_07.jpg

图 7.7：编辑默认安全组的入站规则

1. 选择添加规则，然后按以下步骤操作：

   • 对于类型，请选择HTTP协议。

   • 对于来源类型（入站规则），请执行以下操作以允许流量：

     • 选择IPv4 任何位置以允许来自任何 IPv4 地址的传入流量（入站规则）。完成此操作后，将自动为 0.0.0.0/0 IPv4 CIDR 块添加规则。

     • 请提供此安全组规则的简短描述：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_08.jpg

图 7.8：向默认安全组添加 HTTP 规则

1. 选择保存规则。

第 4 步 – 创建一个 ECR 注册表

开始使用 Amazon ECR，在 Amazon ECR 控制台中设置一个仓库。Amazon ECR 控制台提供了逐步指南，帮助您创建初始仓库。在开始之前，请确保您已按照Amazon ECR 设置指南中概述的所有必要步骤操作：docs.aws.amazon.com/AmazonECR/latest/userguide/get-set-up-for-amazon-ecr.html。

要通过 AWS 控制台建立镜像仓库，请按照以下步骤操作：

1. 仓库是 Amazon ECR 中 Docker 或Open Container Initiative (OCI)镜像的存储位置。在与 Amazon ECR 交互时，您需要提供仓库和注册表位置，以指示镜像的目的地或来源。

   您可以通过访问console.aws.amazon.com/ecr/来访问 Amazon ECR 控制台。

2. 为确保本练习顺利进行，强烈建议您选择us-east-1地区：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_09.jpg

图 7.9：选择正确的 AWS 地区以操作 un

1. 选择开始。

2. 在可见性设置下选择私有。

3. 为确保本练习顺利进行，强烈建议您选择embracing-devops-release-management作为您的仓库名称值。

重要提示

注意显示在 ECR 仓库名称开头的 12 位数字。这是您的 AWS 账户号码，您将需要它来完成本指南中的后续步骤。

或者，您可以浏览您的AWS 账户页面以获取您的 AWS 账户号码：console.aws.amazon.com/billing/home?#/account。

1. 对于标记不可变性，请选择保持禁用状态：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_10.jpg

图 7.10：建立 ECR 仓库（注册表）

1. 选择推送时扫描来启用该仓库的图像扫描功能。如果 ECR 仓库启用了推送时扫描，每当有推送请求时，它将自动开始扫描图像；否则，用户必须手动启动扫描过程。

2. 对于KMS 加密设置，选择禁用它：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_11.jpg

图 7.11: 完成 ECR 仓库创建过程

1. 选择创建仓库。

第五步 – 创建 ECS 集群

通过用户友好的 Amazon ECS 控制台，可以轻松创建一个 Amazon ECS 集群。

在继续操作之前，确保你已经完成了设置 Amazon ECS的前提步骤（docs.aws.amazon.com/AmazonECS/latest/developerguide/get-set-up-for-amazon-ecs.html），并为所选的 IAM 用户分配了正确的 IAM 权限。更多详细信息和帮助，请参考文档中的集群示例部分（docs.aws.amazon.com/AmazonECS/latest/developerguide/security_iam_id-based-policy-examples.html#IAM_cluster_policies）。

Amazon ECS 控制台通过创建 AWS CloudFormation 堆栈，提供了一种简便的方法来生成 Amazon ECS 集群所需的资源。

要通过 AWS 控制台建立 ECS 集群，请按照以下步骤操作：

1. 通过访问 console.aws.amazon.com/ecs/v2 来进入 Amazon ECS 控制台。

2. 为确保本次操作顺利进行，强烈建议选择us-east-1区域。

3. 从导航窗格选择集群。

4. 从集群页面选择创建集群：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_12.jpg

图 7.12: 建立 ECS 集群

1. 在 embracing-devops-release-management 作为集群名称，以确保此次操作顺利进行。

2. 展开基础设施，然后选择AWS Fargate（无服务器）：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_13.jpg

图 7.13: 将 ECS 集群配置为 AWS Fargate（无服务器）

1. 展开监控，然后切换启用容器洞察来启用容器洞察。

2. 展开标签，然后配置标签以帮助识别你的集群。

3. 要添加标签，选择添加标签并执行以下操作：

   • 在密钥字段中输入密钥名称

   • 在值字段中输入值名称

4. 要删除标签，选择标签键和值右侧的删除：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_14.jpg

图 7.14: 对 ECS 集群基础设施进行标签标记

1. 选择创建。

第六步 – 创建 ECS 任务定义

你可以通过控制台或编辑 JSON 文件来创建任务定义。

要通过 AWS 控制台 JSON 编辑器建立任务定义，请按照以下步骤操作：

1. 为确保此操作顺利进行，强烈建议你选择us-east-1区域：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_15.jpg

图 7.15：选择正确的 AWS 区域进行操作

1. 首先，在你 fork 的仓库中编辑 ECS 任务定义 文件：

   1. 在 GitHub 上，点击此书仓库中的 task-definition.json 文件（github.com/PacktPublishing/Embracing-DevOps-Release-Management/blob/main/chapter07/task-definition.json）。

   2. 从 task-definition.json 文件页面，点击铅笔图标以编辑文件：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_16.jpg

图 7.16：在 GitHub 文本编辑器中编辑 ECS 任务定义

1. 定位到表示你 AWS 账户 ID 的两个占位符，它由 12 个连续的“X”字符组成：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_17.jpg

图 7.17：定位到 AWS ID 占位符

1. 用你实际的 AWS 账户 ID 替换两个占位符，并选择提交更改：

注意

你可以浏览你的AWS 账户页面以获取 AWS 账户号码： https://console.aws.amazon.com/billing/home?#/account。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_18.jpg

图 7.18：用你的 AWS ID 替换占位符

1. 在提交确认菜单中，添加有意义的提交信息，并选择直接提交到 主分支：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_19.jpg

图 7.19：在 GitHub 文本编辑器中提交你的更改

1. 然后，选择提交更改。

2. 通过访问 console.aws.amazon.com/ecs/v2 进入 Amazon ECS 控制台。

3. 从导航窗格中选择任务定义。

4. 从创建新任务 定义页面的菜单中选择使用 JSON 创建新任务定义：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_20.jpg

图 7.20：使用 JSON 创建新任务定义

1. 在 JSON 编辑器窗口中修改你的 JSON 文件。

   复制之前编辑的 task-definition.json 文件，并将其粘贴到 JSON 编辑器框中：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_21.jpg

图 7.21：复制你之前编辑的 task-definition.json 文件

注意

如果 JSON 编辑器框中已有内容，在粘贴自定义的task-definition.json文件之前，请确保先将其删除。JSON 编辑器框必须为空，才能将task-definition.json文件的内容添加进去。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_22.jpg

图 7.22：确认并创建 ECS 任务定义

1. 选择创建。

第 7 步 – 创建 ECS 服务

控制台支持快速创建和部署服务。

通过 AWS 控制台建立 ECS 服务，请按照以下步骤操作：

1. 为确保本练习顺利进行，强烈建议选择us-east-1区域：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_23.jpg

图 7.23：选择正确的 AWS 区域进行操作

1. 通过访问console.aws.amazon.com/ecs/v2，进入 Amazon ECS 控制台。

2. 从导航窗格中选择集群。

3. 在集群页面，选择要在其中创建服务的集群。

4. 从服务选项卡中选择创建选项：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_24.jpg

图 7.24：为 ECS 任务创建新 ECS 服务

1. 在部署配置部分提供关于应用程序部署的详细信息：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_25.jpg

图 7.25：配置新 ECS 服务的启动类型

1. 在计算选项下，选择启动类型。

2. 在应用类型下选择服务：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_26.jpg

图 7.26：命名和配置 ECS 服务

1. 在任务定义区域，选择您希望应用的版本和系列。

2. 为确保本练习顺利进行，强烈建议在服务名称下选择embracing-devops-release-management。

3. 要指定期望任务，输入要在服务中启动和管理的任务数量。

4. 对于网络，默认的 VPC 及其关联的网络配置应自动填充到字段中。然而，确保配置与以下内容相似：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_27.jpg

图 7.27：选择默认 VPC 进行网络配置 – 公共 IP！

1. 为资源打标签是定位云基础设施的好方法，特别是在创建了数百或数千个资源之后，打标签特别有用。

   要为 ECS 服务添加标签，展开标签，然后配置标签以帮助识别服务和任务。

2. 要添加标签，选择添加标签，然后执行以下操作：

   • 在密钥字段中输入密钥名称。

   • 在值字段中输入值名称。

3. 要移除标签，选择标签键值对右侧的移除选项。

4. 选择创建。

这标志着本指南的第一部分——AWS 基础设施的配置——的结束。在这一部分中，你已配置了支持第二部分指南中概述的 CICD 流水线操作所需的基础设施，即配置 GitHub Actions 工作流。

让我们简要回顾一下你迄今为止的成就：

• 你已经确保你的 AWS IAM 用户已分配必要的权限，以便能够在你的 AWS 账户内配置所需的云资源。

• 你已经确保你的 AWS 账户配备了默认 VPC 及相关的默认网络资源。

• 你已经修改了默认 VPC 中的默认安全组，以便它包含一个 HTTP 规则。这是为了允许用户通过 80 端口访问你的网页应用，我们将在本指南的第二部分进行部署。

• 你已经创建了必要的ECS 注册表，用于存储由 GitHub 工作流生成的 Docker 镜像。我们将在本指南的下一部分进行配置。

• 你已经创建了必要的ECS 集群，用于托管由 GitHub Actions 工作流生成并部署的 Docker 容器。我们将在本指南的下一部分进行配置。

• 你已经创建了必要的ECS 任务定义，它将管理你的网页应用部署的操作活动。这确保了网页应用部署在所有适当配置下运行，并能在遇到意外的系统问题时保持弹性。

• 你已经创建了与配置的 ECS 任务定义关联的必要ECS 服务。这是为了确保所需的网络基础设施已经搭建好，以便用户能够从本地网页浏览器访问在 ECS 中运行的网页应用。

在本指南的下一部分——配置 GitHub Actions 工作流——你将学习如何配置 GitHub Actions 工作流。在这一部分中，你将启用必要的后端设置，学习如何配置输入参数并将秘密信息注入构建过程中，了解如何启动流水线运行并分析构建日志。最后，你将学习如何访问部署到 ECS 中的网页应用，并验证它的存在。

配置 GitHub Actions 工作流

如果希望成功运行 GitHub Actions 工作流并实现成功的部署，则需要进行多个配置。主要的配置项是输入参数，它们以变量和密钥的形式存在。值得注意的是，密钥与变量几乎完全相同，唯一的区别是，密钥在日志中会被掩码，且配置完毕后不会对任何人可见。成功启动流水线运行后，您可以查看日志输出，验证任何问题、失败和成功。最后，您将能够看到在 AWS EC2 中运行的功能性 Web 应用程序。

先决条件

要完成本阶段的指南，您需要确保拥有一个有效的 GitHub 账户（github.com/），并且账户状态良好。

步骤 1 – 配置所需的 GitHub 仓库变量和密钥

配置 GitHub Actions 后端是一个简单的过程，但了解需要关注的内容会有所帮助。在此步骤中，您将为此仓库启用 GitHub Issues，这样如果在构建过程中标记到问题，流水线可以自动提出问题。关键的是，我们还将配置流水线变量和密钥，以便在运行过程中可以将其注入到流水线中。这是 DevOps 中的标准技术，允许相同的 CI/CD 流水线脚本在多个环境中运行，并根据每个用例的独特设置进行配置，包括您的！

为了建立所需的 GitHub 仓库变量和密钥，请按照以下步骤操作：

1. 在 GitHub 中，导航到 embracing-devops-release-management 仓库：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_28.jpg

图 7.28：导航到您分叉仓库中的设置菜单

1. 为此仓库启用 GitHub Issues：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_29.jpg

图 7.29：为您的分叉仓库启用 GitHub Issues

1. 在仓库菜单的 Security 部分，导航到 Secrets and variables 选项：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_30.jpg

图 7.30：访问 GitHub Actions 的密钥和变量选项

1. 然后，选择 Actions。

2. 在 Actions 密钥和变量 菜单中，选择 Secrets 标签。

3. 然后，选择 新建 仓库密钥：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_31.jpg

图 7.31：向 GitHub Actions 仓库添加密钥

您需要为 GitHub Actions 工作流提供在您的 AWS 账户中配置资源的权限。为此，您需要提供 AWS 访问密钥，以便在流水线中运行 AWS CLI 操作。

1. 为您的 AWS 访问密钥 ID 创建一个新的仓库密钥，然后按照以下步骤操作：

   1. 在 AWS_ACCESS_KEY_ID 中。

   2. 在 Secret 字段中，输入您的 AWS 访问密钥 ID 的值。

   3. 选择 添加密钥：

注

密钥是你在仓库、组织或环境中设置的环境变量。通过 GitHub Actions，你可以将你提供的密钥集成到你的工作流中。如果你故意在工作流中包含密钥，那么 GitHub Actions 将在管道运行过程中读取该密钥。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_32.jpg

图 7.32：将 AWS 访问密钥 ID 添加为管道密钥

警告

GitHub 会自动从作业生成的任何日志中删除对密钥的任何提及。建议不要故意将密钥发布到日志中。

1. 为你的 AWS 秘密访问密钥 ID 创建一个新的仓库密钥：

   1. 在AWS_SECRET_ACCESS_KEY中。

   2. 在Secret字段中，输入你的 AWS 秘密访问密钥的值。

   3. 选择添加密钥：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_33.jpg

图 7.33：将 AWS 秘密访问密钥添加为管道密钥

1. 在Actions 密钥和变量菜单中，选择变量标签。

2. 然后，选择新建 仓库变量：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_34.jpg

图 7.34：向 GitHub Actions 仓库添加变量

1. 为你的ECR_REGISTRY创建一个新的仓库变量。

2. 在XXXXXXXXXXXX.dkr.ecr.us-east-1.amazonaws.com中作为你的 ECR 仓库地址。

注意

别忘了在输入文本框时，使用你自己的 AWS 账户 ID，填入完整的 ECR 仓库地址。

存储和重用非敏感配置信息的一种技术是通过变量。变量是保存配置信息的好方法，例如编译器标志、用户名和服务器名称。执行你工作流的 runner 负责插入变量，这些变量可以在操作或工作流阶段的命令中创建、读取和修改。

1. 选择添加变量：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_35.jpg

图 7.35：填写 GitHub Actions 仓库变量的示例

警告

默认情况下，变量会在构建输出中显示未掩码的内容。如果你需要对敏感信息（如密码）进行更高的安全保护，请使用密钥。

1. 输入管道成功运行所需的其他仓库变量。

2. 重复步骤 11中提到的过程，直到所有剩余的仓库变量都已添加：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_36.jpg

图 7.36：所有必要的管道变量示意图

以下表格包含所有必需的变量名称及其建议值：

变量名称	变量值
ECR_REGISTRY	XXXXXXXXXXXX.dkr.ecr.us-east-1.amazonaws.com
MY_AWS_REGION	us-east-1
MY_CONTAINER_NAME	embracing-devops-release-management
MY_ECR_REPOSITORY	embracing-devops-release-management
MY_ECS_CLUSTER	embracing-devops-release-management
MY_ECS_SERVICE	embracing-devops-release-management
MY_ECS_TASK_DEFINITION	./``chapter07/task-definition.json

表 7.1：一个包含所有必要变量的实用图表

注意

确保在为 MY_ECS_TASK_DEFINITION 设置的值前面加上 ./。这是一个必要的文件系统路径，是 GitHub Actions 获取 task-definition.json 文件并在管道中使用它所需的有效语法。

步骤 2 – 启动 GitHub Actions 工作流

终于到了执行管道的时候。这是关键时刻，我们将完成我们设定的目标。按照以下步骤来启动 GitHub Actions 工作流并将你的 Docker 容器部署到 ECS：

1. 导航到 GitHub Actions 菜单：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_37.jpg

图 7.37：访问 GitHub Actions 菜单

1. 选择 I understand my workflows, go ahead and enable them：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_38.jpg

图 7.38：启用 GitHub Actions 使用权限

1. 从 All workflows 菜单中，在 Actions 下选择本次练习的工作流，并选择 Deploy to Amazon ECS：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_39.jpg

图 7.39：导航到 Deploy to Amazon ECS 工作流菜单

1. 在 Deploy to Amazon ECS 工作流菜单中，选择 Run workflow，然后点击 Run workflow：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_40.jpg

图 7.40：启动 GitHub Actions 工作流运行

上面的截图展示了你在本次练习中配置、构建并部署的 Deploy to Amazon ECS GitHub Actions 工作流的主菜单。在这里，你可以启动新的工作流运行，并查看当前和之前的工作流运行历史。

在管道运行启动后，会在该 GitHub Actions 工作流的构建历史中新增一条记录。当工作流运行时，构建历史中该条记录左侧会显示黄色指示器。管道完成后，如果构建失败，黄色指示器会变为红色；如果构建成功，则变为绿色：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_41.jpg

图 7.41：一个正在运行的 GitHub Actions 工作流

步骤 3 – 分析部署日志

在此步骤中，我们将仔细审查在上一步骤中运行的 GitHub Actions 工作流的构建日志。此管道中有三个主要阶段。第一阶段进行静态代码分析测试。第二阶段将 Web 应用程序构建成 Docker 镜像。最后，最后阶段进行动态应用安全测试，以评估部署到 ECS 后的容器。所有这些活动将在完成后记录在 GitHub Actions 构建日志中。

一旦 GitHub Actions 工作流启动，点击管道阶段以查看失败、问题和成功的日志！

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_42.jpg

图 7.42：构建历史区域中单个工作流的详细菜单

如下截图所示，管道已分为两个主要阶段：测试和构建与部署。然而，需要注意的是，在管道的构建与部署阶段，在部署完成后和管道阶段结束之前，会进行动态应用安全测试。你可以访问每个阶段的详细信息和历史记录，以查看与每个阶段相关的构建日志：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_43.jpg

图 7.43：检查工作流的不同管道阶段

每个管道阶段的图形表示非常方便，可以快速评估其状态并通过职责的逻辑划分进行组织。在这个仪表盘中，你可以快速查看谁触发了管道、与更改相关的 Git 提交、管道运行的时间以及结果产生了多少工件，所有信息一目了然！当你查看单次管道运行时，这些信息足够有用，但当你在历史记录中解析数百个或数千个构建日志时，这些信息使得理解变得更加容易。

以下截图显示了与 GitHub Actions 工作流的测试阶段相关的活动。正如你所看到的，包括由不同工具进行的两个 SAST——HTMLTest 和 SAST SCAN。两个测试一起检查代码库并尝试识别与 DOM、NodeJS、JSON、YAML、软件依赖项以及源代码中存在的凭证相关的潜在问题。如果所有测试通过，GitHub Actions 工作流的测试阶段将以绿色勾号结束，管道将继续进入构建与部署阶段：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_44.jpg

图 7.44：管道中运行的 SAST 扫描示意图

以下截图展示了 GitHub Actions 工作流中的应用构建阶段。在 构建与部署 阶段，配置了 AWS 凭证，web 应用被构建并标记为新的 Docker 镜像，然后将新的 Docker 镜像发布到 ECR 仓库（注册表）。接着，更新 ECS 任务定义，以反映新的 Docker 镜像标签。最后，新的 Docker 容器被部署到 ECS：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_45.jpg

图 7.45：GitHub Actions 工作流中的构建与部署阶段

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_46.jpg

图 7.46：准备在 ECS 中部署新构建的 Docker 镜像

如下图所示，应用程序已经部署并运行在 ECS 中。随后，在工作流运行期间执行了一个自动化脚本，动态捕获 web 应用的公共 IP 地址，并将其作为环境变量存储在 shell 中。这个过程是通过 AWS CLI 完成的，并且在 GitHub Actions 运行器上执行。捕获 IP 地址后，它会作为 OWASP ZAProxy 扫描器的目标，进行 DAST 扫描。如果 OWASP ZAProxy 检测到任何问题，会自动在仓库中打开一个新的 GitHub 问题以供人工审查：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_47.jpg

图 7.47：在工作流中运行 DAST 扫描

如下图所示，OWASP ZAProxy 已完成扫描，扫描结果显示在构建日志中。在 GitHub Actions 工作流中的所有操作完成后，管道会清理构建环境，并取消设置所有使用过的机密和环境变量。此时，GitHub Actions 运行器将被优雅地停用：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_48.jpg

图 7.48：查看 OWASP ZAProxy web 应用扫描结果

步骤 4 – 观察在 AWS ECS 中运行的已部署应用程序

现在 GitHub Actions 工作流已经完成，web 应用已部署到 ECS，让我们打开浏览器窗口，查看我们的成果。

你可以通过两种简单的方法获取正在运行的 web 应用的公共 IP 地址：

1. 查看部署日志后，你可以找到用于扫描运行中 web 应用的 IP 地址，这个 IP 地址是在使用 OWASP ZAProxy 进行自动扫描时获得的：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_49.jpg

图 7.49：查找已部署 web 应用的公共 IPv4 地址

1. 打开 AWS Web 控制台，获取 ECS 服务的 IP 地址：console.aws.amazon.com/ecs/v2：

注意

别忘了选择正确的 AWS 区域，确保你的 ECS 集群已部署在该区域。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_50.jpg

图 7.50：在 AWS 中导航到 ECS 集群菜单

1. 导航到你的 ECS 集群：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_51.jpg

图 7.51：访问你的 Web 应用的 ECS 集群

1. 点击与 Web 应用部署相关的 ECS 任务：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_52.jpg

图 7.52：导航到你的 Web 应用的 ECS 任务菜单

1. 点击与你的 ECS 任务部署相关的当前部署哈希值：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_53.jpg

图 7.53：访问你 ECS 任务的最新版本

1. 在公网 IP标题下查找，以获取你的 Web 应用的公网 IP 地址：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_54.jpg

图 7.54：查找你的 Web 应用当前的公网 IPv4 地址

1. 如果一切顺利，并且你的 GitHub Actions 工作流已成功运行，你应该能够浏览 Web 应用并亲自体验。以下截图展示了你在用 Web 浏览器访问 Web 应用时应该看到的内容：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/embr-dop-rls-mgt/img/B21803_07_55.jpg

图 7.55：在 AWS ECS 中浏览你的 Web 应用！

你部署到 ECS 中的 Web 应用是一个简单的网站，使用 Bootstrap 网页框架构建。

总结

这结束了第七章。在这一章中，你已看到一个简单的 CI/CD 流水线代码示例，该代码作为 GitHub Actions 工作流编写。在接触到 CI/CD 流水线语法后，你现在对流水线的构成方式以及如何进行版本控制有了基本的理解。这意味着你具备了阅读、编写和理解流水线文件的能力，并能够确定每个步骤中执行的活动。此外，你还了解了如何使用 ClickOps 配置 AWS 基础设施。凭借这些基础知识，你可以提升自己的技能，并朝着更先进的基础设施部署策略——即基础设施即代码（IaC）迈进。不仅如此，你还获得了配置 GitHub Actions 后端所需的基本知识。因此，通过这些活动，你现在可以准备涵盖 DevOps 发布管理原则（如测试、构建和将应用作为 Docker 容器部署到云中的端到端工作流）！最后，你还获得了撰写附带软件发布的有用文档（包括更新日志）的基础知识。

在下一章中，我们将讨论 CI/CD 流水线如何促进良好的 DevOps 发布管理。主题包括平衡 CI/CD 治理与市场速度、制定团队的分支策略、构建发布流水线，并实现适合 DevOps 发布管理的变更审批流程。

资源

要深入了解本章所涉及的主题，请查看以下资源：

• docs.aws.amazon.com/AmazonECS/latest/userguide/getting-started-fargate.html

• docs.aws.amazon.com/AmazonECS/latest/userguide/create-container-image.html

• docs.aws.amazon.com/AmazonECS/latest/userguide/get-set-up-for-amazon-ecs.html

• docs.github.com/en/actions/deployment/deploying-to-your-cloud-provider/deploying-to-amazon-elastic-container-service

• earthly.dev/blog/github-actions-and-docker/

问题

回答以下问题，测试你对本章内容的掌握情况：

1. 什么是 GitHub Actions 工作流？

2. 什么是 ClickOps？

3. 什么是 AWS 访问密钥？

4. 什么是 AWS IAM 策略？

5. 什么是 GitHub 仓库的 “fork”？

6. 什么是 AWS 安全组？

7. 什么是 ECS 集群？

8. 什么是容器镜像仓库？

9. 什么是环境变量？

10. 什么是 README.md 文件？