按照当今的标准，传统的 IT 组织通常具有极长的开发周期。在这些陈旧的公司中，通常在将软件产品发布到生产环境之前，必须进行大量的手动测试。此外，任何代码更改都可能给相关利益相关者带来巨大的压力。在这样的组织中工作时，开发团队通常要等待清洁的环境配置好，或者在进行任何更改之前必须等待批准。此外，质量保证（QA）团队可能要等开发人员完成工作后才能进行测试。所有这些等待导致了低部署频率 (DF) 和高变更前置时间 (LTFC)。
此外，在传统的 IT 组织中，许多团队成员在项目完成后就退出了，留下的文档很少，知识传递为零。这使得新工程师加入团队并尝试支持系统时面临挑战。通常，这会导致关键问题发生时平均恢复时间 (MTTR) 更长。许多这样的组织通过专门的运营团队来管理其环境配置，该团队的唯一重点是基础设施。他们通常会对服务器进行手动更改，导致配置漂移，即使基础设施即代码 (IaC) 是公司的标准程序。跨环境的服务器可能最终具有不同的工件，例如应用程序所需的库或同一产品的不同补丁级别。所有这些手动工作导致低 DF 和高前置时间。
在本章中，我们将探讨 DevOps 发布管理如何通过引入自动化、减少风险、简化发布流程，并通过跟踪指标和分析关键绩效指标 (KPI) 来衡量成功，从而解决这些问题。我们将阐述 DevOps 的特性为何使其在发布管理方法中脱颖而出，尤其是在基于云的微服务部署的背景下。
因此，本章将涵盖以下主题：
- 探讨自动化测试、部署和变更管理
- 减少潜在风险并加速软件产品发布
- 简化发布流程，使其标准化
- 改进成功发布的指标和关键绩效指标 (KPI)
探索自动化测试、部署和变更管理
在软件开发过程中，大多数现代组织面临着几个重大障碍：快速部署软件和大规模创新。DevOps 方法旨在通过在整个软件开发生命周期 (SDLC) 中实施自动化来应对这些挑战，其目标是加快可靠且安全的软件交付。
通过整合自动化测试、自动化部署和自动化变更管理，DevOps 发布管理为运营团队自动化发布计划铺平了道路。使用自动化使发布管理成为一个易于复制、可重复的过程，从而更容易管理和交付成功的发布。通过实施精心设计的持续集成/持续部署 (CI/CD) 管道，使其在整个组织中兼容，但同样重要的是要确保它们的可靠性。
毫无疑问，自动化一个包含持续发布和 CD 的 DevOps 框架可能非常复杂。在整个应用程序开发过程中，必须结合全面的测试、广泛的跨团队沟通、先进的工具和工作流程程序，才能在你的组织中实现持续发布。
在接下来的子章节中，我们将讨论自动化测试这一至关重要的主题，它是 DevOps 哲学的生命线。
自动化测试
在 CI/CD 管道中尽早且频繁地部署自动化测试一直是 DevOps 的创始特征之一。这包括主动监控生产环境，以发现可能会对用户产生负面影响的问题。现实情况是，现代应用程序依赖于众多工件和服务，并存在多个故障点。除了在管道中使用静态和动态应用程序分析工具外，重要的是你要在所有开发环境中进行事务监控，而不仅仅是生产环境。通过使用模拟数据和持续监控进行测试，你可以检测到影响应用程序任何组件的问题，包括第三方软件即服务 (SaaS) 集成。Datadog、Dynatrace、New Relic、Snyk 和 Prisma Cloud 是一些能够促进这一过程的有效 SaaS 工具。
随着开发团队不断完善 DevOps 实践，他们将希望在整个 SDLC 中实施测试自动化，因为这是充分利用 DevOps 的关键。这些好处包括更快、更一致地构建、测试和发布的能力。为了改进事件响应 (IR)，鼓励合作，并在团队之间进行有效沟通，再也无法接受新代码在手动 QA 测试中耗费数小时甚至数天，才让软件开发人员获得工作反馈。QA 团队必须围绕 DevOps 发布管理生命周期调整工作，确保测试用例自动化，并在可行的情况下实现完整的代码覆盖。环境配置需要通过使用 IaC 进行标准化，部署应自动且不可变地进行。换句话说，任何预测试任务，例如基础设施配置、环境配置、后测试任务、清理或相关的可重复且单调的项目，都应自动化，以符合 CI 的理念。
自动化测试是 CI 的关键优势，它节省了你的资源，使你能够实现规模经济。首先，自动化测试最大限度地提高了在错误进入生产之前被捕获的可能性。它还通过在检测到错误和缺陷后立即通知你来加快发布过程。此外，实施 CI 的一个显著优势是，小团队能够成功执行更繁重的任务。并行集成使你能够快速连续执行多个自动化测试，每个测试通常在几分钟内完成，从而进一步减少了测试开支。虽然自动化整个开发过程可能看起来令人望而生畏，但你可以从小规模开始，自动化一个端到端的过程，并定期运行它。新工具和资源使自动化测试比以往任何时候都更易于实现，而其带来的好处也证明了这笔投资的合理性。自动化测试使你能够消除瓶颈并提高生产力，通常会提高员工和客户的满意度，以及公司银行账户中的收入。
自动化测试带来的一个重要优势是能够以当今现代数字市场的速度扩展运营。DevOps 技术在降低风险的同时具有提供一致质量的良好记录。这部分通过将工作分配给多个自给自足的小团队来实现，这些团队作为一个整体合作的集体。这种集体开发风格鼓励团队成员之间分享各自的技术和想法，同时在业务单位 (BU) 内灌输共同的理念。由于自动化测试带来的巨大生产力提升，你将体验到更好的团队合作。你的同事们不再需要将大量时间和精力花在手动测试协议上。相反，团队将有更多机会讨论优化策略或进行团队午餐。因为你选择了采用 DevOps 文化，你选择了对质量的共同责任，这在团队成员中灌输了自豪感。现在，你可以看到自动化测试是 DevOps 的基石。
DevOps 发布管理可以帮助你提高基础设施和业务流程的可靠性。此外，当你通过增加测试自动化覆盖率来提高发布的可靠性时，生产中的问题将变得罕见。这些特性的总和创造了一个同事们喜欢的工作环境。所有这些 DevOps 发布管理方法的标志性特点都会增加客户的满意度。事实证明，更好的可靠性和及时响应客户反馈会提高客户满意度，并鼓励更多人向他人推荐你公司的产品。
自动化部署
CD 的核心是一个统一的发布过程，包含自动化的构建、测试和部署步骤。目标是简化将新软件推向生产的操作。每个企业都必须确定构成其独特测试套件的单元测试、功能测试和压力测试的组合。为了成功地分阶段测试构建和发布候选版本，至关重要的是在发布前的测试基础设施中模拟生产环境条件。
通过使用 CD 管道，可以自动将代码更改推向生产，这只是一个结合了构建、测试和部署的自动化工作流。一个工作流阶段的输出成为下一个工作流阶段的输入，依此类推。通过 DevOps 方法，CD 通过在每个流程阶段执行自动化测试和监控，可以防止错误、功能问题和缺陷。通过这种方式，任何可能落入主分支的问题都在进入生产之前就被发现。
最终结果是工程团队能够在主分支上实施代码更改，并迅速看到它们在生产环境中的部署，通常在几分钟内完成。这种软件开发理念强调 DevOps 的基本目标，即持续为终端用户提供价值。这也是在众多应用程序和基于 Web 的服务中引入新功能和系统修改的主要推动力。
一旦 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% 的正常运行时间至关重要，并且不会丢失数据。当 DR 规划成为组织 DevOps 管道策略的一部分时，它通常会与应用程序本身一起进行管理，以便定期验证两者的更改。通过将 DR 规划纳入 DevOps 工作流，恢复过程实际上被转化为类似于部署应用程序的过程。这不仅减少了错误的可能性，还加快了新软件应用程序的发布。在危机发生时，你的团队可以利用他们在部署方面的专业知识来促进恢复过程。
此外，复制数据的 DR 环境可以为恢复工作做出贡献。毫无疑问，将应用程序从开发转移到 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 指标，软件交付性能可以得到客观衡量和优化，并且可以证实对业务的价值：
DORA 方法包括四个关键指标，如下所述，用于评估 DevOps 的两个基本维度：即速度和可靠性。DevOps 团队的速度测量由其 DF 和平均 LTFC 决定，而可靠性测量则由其变更失败率 (CFR) 和恢复服务时间 (TTRS) 指标决定。综合分析这四个 DORA 指标，可以为 DevOps 团队的成功建立一个基本的衡量标准，并指出可能需要改进的领域。
LTFC
LTFC 被认为是 DevOps 团队需要监控的关键指标之一。LTFC 的概念不应与周期时间混淆。LTFC 是指从代码更改提交到主分支的那一刻到其变为可部署状态（例如，当新代码成功通过所有所需的预发布测试时）之间的时间。
通常，表现卓越的团队倾向于以小时为单位量化交付时间，而表现较差的团队则倾向于以天、周甚至月为单位量化交付时间。改善周转时间需要结合测试自动化、基于主干的开发、精心设计的反馈循环以及迭代的、增量的工作。只有遵循这些原则，开发人员才能快速评估其代码的编写质量，并在发布之前修复发现的任何缺陷。当多个开发人员在不同的分支上并行进行重大更改，并依赖手动测试来确保质量时，交付时间不可避免地会大幅增加。
CFR
变更失败率 (CFR) 是指在代码发布给消费者后导致问题并需要修复的变更百分比。这不包括在测试中发现并在代码发布之前修复的错误。
表现出色的团队通常表现出 0% 到 15% 范围内的 CFR。降低 CFR 与使用相同的方法（测试自动化、基于主干的开发和小批量工作）相关联，这些方法也缩短了交付时间。通过实施这些程序，发现和修复错误的负担大大减轻。监控和报告 CFR 对于定位和纠正问题以及确保新发布的代码满足所有必要的安全标准至关重要。
DF
DevOps 成功的重要衡量标准之一是新代码推向生产的频率。许多专业人士使用"交付"一词指代代码更改发布到预生产环境，而使用"部署"一词指代代码更改发布到生产环境。
最优秀的团队可以随时推出更新，一天可以多次推出更新。表现较差的团队通常只能每周或每月部署一次。按需部署的能力要求配备自动化部署管道，该管道不仅包含前面提到的自动化测试和反馈机制，还减少了所需的手动干预。
MTTR
MTTR 是指在部分中断或服务完全中断后恢复操作所需的时间。不管中断是由于最近的部署、单个服务器故障还是其他原因导致，跟踪这个指标都是至关重要的。表现出色的团队通常能够在不到一小时的时间内迅速从系统故障中恢复。而表现较差的团队可能需要一周的时间才能完全恢复。
对 MTTR 的重视与传统上强调的平均故障间隔时间 (MTBF) 有所不同。这反映了当前程序的复杂性以及它们出现故障的可能性。此外，这也鼓励了不断追求改进的习惯。团队现在会持续部署，而不是为了避免任何失败而等待发布变得完美。MTTR 鼓励无责备回顾，团队可以通过回顾来改进其上游流程和工具，而不是寻找替罪羊来为表面上完美的 MTBF 记录中断负责。
另一个需要跟踪的相关统计数据是周期时间，即产品从团队工作到发货所需的时间。开发周期时间是指从开发人员提交代码到推送到生产环境的时间。这一关键的 DevOps 指标对项目经理和工程经理来说非常有用，可以深入了解开发管道的成功因素。因此，他们将能够确保团队的工作更加符合利益相关者和客户的期望，从而更快地交付产品。
项目经理可以使用周期时间报告为其 CI/CD 管道定义一个基本的基线，然后可以用于评估未来的操作。当团队优先优化周期时间时，开发人员通常会减少其工作中的进度 (WIP) 并减少无效活动的发生率。
总结
在你能够有效使用 DevOps 发布管理之前，了解它旨在解决的问题至关重要。阅读本章后，你应该对 DevOps 生命周期的许多关键方面有一个基本的了解。你现在明白了将自动化技术应用于测试、部署和变更管理的重要性。此外，你还学习了通过发布管道使用的策略，以减少潜在风险并加快软件产品的发布速度。此外，你还了解了以标准化方式简化发布流程所需的步骤。最后，你掌握了改进成功发布和客户满意度指标和 KPI 所需的基础知识。
在下一章中，你将了解是什么使 DevOps 发布管理与其他发布管理模型相比独树一帜。通过学习 DevOps 发布管理哲学，你将了解其与众不同的关键点。你将了解为什么 DevOps 是整体的，并且在你的组织中具有文化意义。此外，你还将了解 DevOps 如何通过整合 CI/CD、QA、安全性和反馈循环来改变游戏规则。你还将了解 DevOps 如何将业务团队纳入开发过程的意义。最后，你将接触到 Gene Kim 的"三种方式" DevOps 原则，并了解传统发布管理方法与 DevOps 之间的区别。