对于软件开发人员来说，编写在自己的机器上运行的代码已经够难了。但即使完成了，从那里到产生价值的软件还有很长的路要走——因为软件只有在生产环境中才能产生价值。我的软件交付理念的本质是构建软件，使其始终处于可以投入生产的状态。我们称之为持续交付，因为我们一直在运行一个部署管道，测试该软件是否处于可交付状态。

持续集成是一种软件开发实践，其中团队的每个成员每天至少将其更改与同事的更改一起合并到代码库中。每次集成都会通过自动构建（包括测试）进行验证，以尽快检测集成错误。团队发现，这种方法可以降低交付延迟的风险，减少集成工作量，并支持采用能够促进代码库健康发展的实践，从而快速增强新功能。

现代源代码控制系统提供了强大的工具，可以轻松地在源代码中创建分支。但最终这些分支必须合并在一起，许多团队花费了过多的时间来处理他们错综复杂的分支。有几种模式可以让团队有效地使用分支，集中于集成多个开发人员的工作和组织生产发布的路径。最重要的主题是应该经常集成分支，并将工作重点放在可以以最小的努力部署到生产环境中的健康主线上。

我们对持续交付进行了一个小时的概述。主题包括持续交付的理由、部署管道、持续集成、DevOps 和部署策略。最精彩的是 Jez 将候选版本拟人化为希腊神话中的英雄。

机器学习应用程序在我们的行业中越来越受欢迎，但是与更传统的软件（例如 Web 服务或移动应用程序）相比，开发、部署和持续改进机器学习应用程序的过程更加复杂。它们在三个方面都会发生变化：代码本身、模型和数据。它们的行为通常很复杂且难以预测，而且更难测试、更难解释和更难改进。机器学习持续交付 (CD4ML) 是将持续交付原则和实践应用于机器学习应用程序的学科。

在 DevOps 文化中集成必要的安全控制和审计功能以满足合规性要求可以利用 CI/CD 管道自动化，但随着组织规模的扩大，这也带来了独特的挑战。了解所选实施方案带来的二阶影响和意外后果是构建有效、安全和可扩展解决方案的关键。

在我们软件系统中，Observability 一直很有价值，在这个云计算和微服务时代更是如此。然而，我们添加到系统中的 Observability 往往处于相当低的级别和技术性质，而且它似乎经常需要在我们代码库中充斥着对各种日志记录、检测和分析框架的粗糙、冗长的调用。本文介绍了一种模式，可以清理这种混乱，并允许我们以一种干净、可测试的方式添加与业务相关的 Observability。

功能切换（通常也称为功能标志）是一种强大的技术，允许团队在不更改代码的情况下修改系统行为。它们属于各种使用类别，在实施和管理切换时必须考虑到这种分类。切换会引入复杂性。我们可以通过使用智能切换实现实践和适当的工具来管理我们的切换配置来控制这种复杂性，但我们也应该致力于限制系统中切换的数量。

传统上，质量保证侧重于在软件发布到生产环境之前对其进行测试，以查看它是否已准备好发布。但越来越多的现代质量保证组织也开始关注在生产环境中运行的软件。通过分析日志和其他监控工具，他们发现了需要向开发组织强调的质量问题。这种方法对于使用持续交付快速可靠地将新版本软件投入生产的组织特别有效。

2010 年在旧金山 QCon 大会上对 Jez Humble 和我的采访

自动化回归测试套件可以在软件项目中发挥至关重要的作用，它不仅可以减少生产中的缺陷，而且对于进化设计也至关重要。在与开发团队交谈时，我经常听到关于非确定性测试的问题——有时通过而有时失败的测试。如果不加控制，非确定性测试会彻底破坏自动化回归测试套件的价值。在本文中，我概述了如何处理非确定性测试。最初，隔离有助于减少它们对其他测试的损害，但您仍然需要尽快修复它们。因此，我讨论了造成不确定性的常见原因的处理方法：缺乏隔离、异步行为、远程服务、时间和资源泄漏。

在这个视频（12 分钟）中，Mike Mason 和我谈论了 功能分支 及其替代方案的弊端。

Rake 是一种构建语言，其用途类似于 make 和 ant。与 make 和 ant 一样，它是一种领域特定语言，但与这两者不同的是，它是一种使用 Ruby 语言编程的内部 DSL。在本文中，我将介绍 rake，并描述一些我使用 rake 构建此网站时发现的有趣之处：依赖模型、合成任务、自定义构建例程和调试构建脚本。

我看到关于敏捷项目最常见的问题之一是如何处理与另一个团队的交接。如果您有一个开发团队离开并将支持工作移交给支持团队，那么当敏捷项目往往比计划驱动的流程产生的文档少得多时，他们如何应对？

我和我的同事敦促客户实现的目标之一是完全自动化的部署流程。自动化部署有助于减少在软件“完成”和实现其价值之间出现的摩擦和延迟。Dave Farley 和 Jez Humble 正在完成一本关于这个主题的书——持续交付。它建立在许多通常与 持续集成 相关的理念之上，更多地推动了这种快速将软件投入生产并使其发挥作用的能力。他们关于蓝绿部署的部分引起了我的注意，因为它是一种未被充分利用的技术，所以我想在这里简要概述一下。

“抽象分支”是一种对软件系统进行大规模更改的技术，它以渐进的方式进行，允许您在更改仍在进行中时定期发布系统。

我已经多次谈到 持续集成 的优点。要使这样的环境正常工作，您需要一个持续集成服务器和一个源代码控制系统。为了使项目顺利进行，您还可以使用问题跟踪器来进行错误跟踪等，并使用 Wiki 来帮助捕获各种项目知识。

金丝雀发布是一种通过先将更改缓慢地推广到一小部分用户，然后再将其推广到整个基础架构并向所有人提供，从而降低在生产环境中引入新软件版本风险的技术。

现代应用服务器经常宣传的功能之一是它们在集群中提供故障转移。集群提高了应用程序的可靠性，如果其中一台服务器出现故障，您还有其他服务器可以为您的客户提供服务。故障转移可以进一步提高可靠性，如果一台服务器在交互过程中出现故障，集群可以将该交互转移到另一台服务器。

然而，这可能是一个问题。

软件系统通常会远程调用在不同进程中运行的软件，这些进程可能位于网络上的不同机器上。内存调用和远程调用之间的一大区别是，远程调用可能会失败，或者在达到某个超时限制之前一直挂起而没有响应。更糟糕的是，如果在无响应的供应商上有许多调用方，那么可能会耗尽关键资源，从而导致跨多个系统的级联故障。Michael Nygard 在其著作《发布它》中推广了断路器模式，以防止这种灾难性的级联故障。

断路器背后的基本思想非常简单。您将受保护的函数调用包装在一个断路器对象中，该对象负责监视故障。一旦故障达到某个阈值，断路器就会跳闸，并且对断路器的所有进一步调用都会返回错误，而根本不会进行受保护的调用。通常，如果断路器跳闸，您还需要某种监视器警报。

自动化配置工具（例如 CFEngine、Puppet 或 Chef）允许您通过提供描述服务器元素配置的配方来避免 雪花服务器。配置同步会在整个生命周期内定期或在更改时将这些规范应用于服务器实例。如果有人在工具外部对服务器进行了更改，则会在下次同步服务器时将其恢复为集中指定的配置。如果需要进行某些配置更改，则在配置规范（配方、清单或特定配置工具的任何称呼）中进行更改，然后将其应用于整个基础架构中的所有相关服务器。

持续交付是一种软件开发原则，您以这样一种方式构建软件：软件可以随时发布到生产环境。

在以下情况下，您正在进行持续交付

• 您的软件在其整个生命周期中都是可部署的
• 您的团队优先考虑保持软件可部署，而不是开发新功能
• 任何人在任何时候对系统进行更改时，任何人都可以获得有关其系统生产准备情况的快速、自动反馈
• 您可以按需将任何版本的软件一键式部署到任何环境

持续集成是软件开发中的一种流行技术。在会议上，许多开发人员会讨论他们如何使用它，而且持续集成工具在大多数开发组织中都很常见。但我们都知道，任何像样的技术都需要一个认证计划——幸运的是，确实存在这样一个计划。它由持续交付和开发运维领域的一位最重要的专家开发，以其管理速度快、结果洞察力强而闻名。虽然它已经相当成熟，但它的知名度还不够高，因此作为该技术的粉丝，我认为与我的读者分享这个认证计划很重要。您准备好获得持续集成认证了吗？您将如何处理考试将揭示的令人震惊的事实？

暗启动一项功能意味着采用新的或更改后的后端行为，并从现有用户那里调用它，而用户无法分辨出它正在被调用。这样做是为了在公开宣布新功能之前评估系统上的额外负载和性能影响。

这是我最近发现的一个有趣的对比。两个规模相似（约 10 万行代码）、环境相似（Java 和 .NET）的企业应用程序项目。一个可以在一小时内完成完整的构建和测试，另一个需要 2-3 分钟。

自动化构建和测试环境的挑战之一是您希望构建速度快，以便能够快速获得反馈，但全面的测试需要很长时间才能运行。部署管道是一种通过将构建分解成多个阶段来解决此问题的方法。每个阶段都提供越来越高的信心，通常以额外的时间为代价。早期阶段可以发现大多数问题，从而提供更快的反馈，而后期阶段则提供更慢、更深入的探测。部署管道是 持续交付 的核心部分。

敏捷软件开发打破了需求分析、测试和开发之间的一些孤岛。部署、运营和维护是其他一些活动，它们与软件开发过程的其他部分也存在类似的分离。DevOps 运动旨在消除这些孤岛，并鼓励开发和运营之间的协作。

回归错误是软件中已经存在一段时间的特性中新出现的错误。在寻找它们时，通常需要弄清楚软件中的哪些更改导致它们出现。查看这些更改可以为了解错误所在以及如何消除错误提供宝贵的线索。这种调查形式没有一个众所周知的术语，但我称之为差异调试。

功能分支是一种源代码分支模式，开发人员在开始开发新功能时会打开一个分支。她在这个分支上完成所有功能方面的工作，并在功能完成后将更改与团队其他成员集成。

支持 功能分支 的最常见论点之一是，它为需要超过一个发布周期的待定功能提供了一种机制。假设您每两周发布一次产品，但需要构建一个需要三个月才能完成的功能。您如何使用持续集成让每个人都在主线上工作，而不会在您的版本中泄露一个半成品的功能？我们经常遇到这个问题，功能标志是一个方便的工具来处理它。

我最喜欢的一句妙语是：如果它很痛苦，就更频繁地做它。它有一个令人愉快的特性，表面上看起来毫无意义，但当你深入挖掘时，它会产生一些有价值的意义

自动化配置工具（例如 CFEngine、Puppet 或 Chef）允许您指定如何配置服务器，并使新机器和现有机器符合要求。这有助于避免脆弱的 雪花服务器 问题。此类工具可以创建可以随意拆除和重建的 凤凰服务器。不可变服务器是这种方法的逻辑结论，一旦部署，服务器就永远不会被修改，只是被一个新的更新实例所取代。

与任何职业一样，软件开发也有其经常被遗忘的活动，这些活动通常被忽略，但往往会在错误的时间反咬一口。其中之一是数据迁移。

基础设施即代码是一种通过源代码定义计算和网络基础设施的方法，然后可以像对待任何软件系统一样对待这些代码。此类代码可以保存在源代码控制中，以允许可审计性和 可重现构建，并接受测试实践和 持续交付 的全面原则。在过去十年中，这种方法一直被用来处理不断增长的 云计算 平台，并将成为未来处理计算基础设施的主要方式。

软件开发团队发现，如果他们尽可能频繁地集成他们的工作，生活就会轻松得多。他们还发现，频繁发布到生产环境中很有价值。但团队不想向用户公开半成品的功能。处理这种紧张关系的一个有用技巧是构建所有后端代码，进行集成，但不构建用户界面。该功能可以集成和测试，但 UI 会一直保留到最后，直到像拱顶石一样，它被添加到完成该功能中，向用户公开。

我是 持续集成 的忠实粉丝，它是一种相对简单的实践，可以对大多数开发团队产生巨大的影响。然而，像大多数实践一样，它也有其缺陷^H^H^H^H^H改进的机会。该主题的 即将出版的标准书籍 的作者 Paul Duvall 最近 指出了 其中之一。如果提交的构建失败，整个团队都会受到影响，并且在修复之前可能会放慢速度。

有一天，我幻想为运营部门启动一项认证服务。认证评估将包括我和一位同事出现在公司数据中心，并用棒球棒、电锯和水枪攻击关键的生产服务器。评估将基于运营团队需要多长时间才能使所有应用程序重新启动并运行。

拉取请求是 github 推广的一种机制，用于帮助合并工作，尤其是在开源项目的上下文中。贡献者在中央存储库的 fork（克隆）中进行贡献。贡献完成后，他们会创建一个拉取请求，通知中央存储库的所有者他们的工作已准备好合并到主线中。工具支持并在接受请求之前鼓励对贡献进行代码审查。拉取请求已在软件开发中得到广泛使用，但批评者担心增加集成摩擦会阻碍持续集成。

当人们想到代码审查时，他们通常会想到开发团队工作流程中的一个明确步骤。如今，在 拉取请求 上执行的集成前审查是最常见的代码审查机制，以至于许多人天真地认为不使用拉取请求就消除了所有进行代码审查的机会。这种狭隘的代码审查观点不仅忽略了许多明确的审查机制，更重要的是忽略了可能是最强大的代码审查技术——整个团队进行的持续改进。

持续集成 (Continuous Integration) 的粉丝们普遍认为，构建应该是可重复的。我们的意思是，在任何时候，您都应该能够获取正在处理的系统的某个旧版本，并以与当时完全相同的方式从源代码构建它。

自测试代码是我在《重构》一书中使用的一个术语，指的是在编写功能软件的同时编写全面的自动化测试。如果做得好，这将允许您调用一个命令来执行测试 - 并且您有信心这些测试将发现隐藏在代码中的任何错误。

那些听过我和我的同事谈论功能分支的人都知道，我们不是这种模式的忠实粉丝。我们反对的一个重要原因是，我们观察到分支很容易，但合并却很难。我们不时听到的一种说法是，现代版本控制工具使合并变得足够容易，因此功能分支是值得的。

维护生产服务器的运行可能是一件麻烦事。您必须确保操作系统和任何其他依赖软件都已正确打补丁，以保持最新状态。托管应用程序需要定期升级。需要定期更改配置以调整环境，使其高效运行并与其他系统正确通信。这需要混合使用命令行调用、在 GUI 屏幕之间跳转和编辑文本文件。

结果就是一个独特的雪花 - 对滑雪胜地来说是好事，对数据中心来说是坏事。

DevOps 状态报告是一份年度报告，它使用调查数据的统计分析来确定软件交付组织的有效实践。其主要作者是 Nicole Forsgren、Jez Humble 和 Gene Kim。

综合监控（也称为语义监控）定期针对实时生产系统运行应用程序自动化测试的子集。结果会被推送到监控服务中，如果出现故障，该服务会触发警报。这种技术将自动化测试与监控相结合，以便在生产环境中检测失败的业务需求。

当人们谈论极限编程时，他们通常关注的是其自适应计划风格或演进式设计方法。一个让我特别感兴趣的小而增长的趋势是，缺陷率极低的 XP 项目数量正在缓慢增加，我指的是每月生产环境中出现不到一个错误。