软件交付指南

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

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

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

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

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

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

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

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

关于持续交付的权威书籍，概述了将代码快速安全地投入生产所需的实践。关键方面是参与发布过程的所有人之间的协作，以及尽可能多地自动化该过程的各个方面。本书介绍了配置管理、自动化测试和持续集成的基础知识，并在此基础上展示了如何构建部署流水线以使集成、测试的代码上线。本书详细介绍了交付生态系统、基础设施管理、环境和数据。

持续交付现在正成为高效软件交付组织的一项核心实践。本次演讲解释了它的工作原理、部署流水线的作用、持续交付和持续部署之间的区别，以及一些重要因素。它还涵盖了持续交付的三个主要好处：降低部署风险、可信的进度和用户反馈。

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

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

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

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

提交/展示/询问是一种分支策略，它结合了拉取请求的功能和保持更改交付的能力。更改分为提交（无需审查即可合并到主线）、展示（打开拉取请求以供审查，但立即合并到主线）或询问（在合并之前打开拉取请求以供讨论）。

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

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

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

我最喜欢的一句妙语是：如果它让你痛苦，就更频繁地去做。这句话表面上看起来毫无意义，但当你深入挖掘时，它会产生一些有价值的含义。

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

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

与任何行业一样，软件开发也有其经常被遗忘的活动，这些活动通常被忽视，但习惯于在错误的时刻反咬一口。其中之一是数据迁移。

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

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

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

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

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

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

在过去几年里，“云”已经成为一个被过度炒作的术语。过度炒作的词语的一个特点是它们几乎没有定义（是的，NoSQL 定义，我正在看着你）。

事实证明，NIST 提供了一个关于云计算的极好定义。它可以通过一份非常简短易懂的 标准文档 获得（不，我不是在开玩笑）。

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

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

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