软件交付指南

持续集成是一种软件开发实践，团队成员经常每天至少合并他们的工作，通常每个人整合 - 导致每天多个集成。每个集成是通过自动化的构建（包括测试），以检测积分误差尽可能快地验证。许多团队发现，这种方法会导致显著减少了合并问题，并且允许团队更快地开发内聚的软件。这篇文章是持续集成的概述，总结技术及其目前的使用情况的简要概述。

敏捷软件开发已经打破了一些需求分析，测试和开发之间的孤岛。部署，运营和维护都已经从软件开发过程的其余部分遭遇了类似的分离等活动。该DevOps的运动是旨在消除这些孤岛，鼓励开发和运营之间的合作。

持续交付是一种软件开发规程，您构建软件的方式可以使软件在任何时候都可以发布到生产环境中。

当你做连续分娩时:

• 你的软件在其整个生命周期中部署
• 您的团队将保持软件的可部署性置于处理新特性之上
• 任何人都可以得到快速，在其系统上的生产准备自动反馈任何时候有人提出了改变他们
• 您可以执行的软件的任何版本的按钮部署按需任何环境

持续集成是软件开发中的一种流行技术。在会议上，许多开发人员谈论他们如何使用它，而持续集成工具在大多数开发组织中是常见的。但我们都知道，任何像样的技术都需要认证程序——幸运的是，确实存在这样一个程序。它是由持续交付和devops领域最重要的专家之一开发的，以管理速度非常快而闻名，但对其结果却非常深刻。尽管它已经相当成熟，但还没有达到应有的知名度，因此作为该技术的爱好者，我认为与我的读者分享这个认证项目是很重要的。你准备好获得持续集成的认证了吗?你将如何应对考试将揭示的令人震惊的真相?

自动化构建和测试环境的挑战之一是，您希望您的构建速度快，以便能够得到快速的反馈，但全面的测试需要很长时间才能运行。部署管道是一种处理这种情况的方法，它将构建分解为多个阶段。每个阶段都提供了越来越多的信心，通常以额外的时间为代价。早期阶段可以发现大多数问题，并提供更快的反馈，而后期阶段通过探索提供更慢的反馈。部署管道是。的中心部分ContinuousDelivery。

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

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

持续交付现已成为有效的软件交付组织中央的做法。本讲座解释它是如何工作的要领，部署流水线的作用，持续交付和持续部署，以及一些重要的成分之间的差异。它也包括持续交付的三个主要优势：降低部署风险，可信的进步和用户反馈。

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

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

我的同事和我敦促客户的目标之一是完全自动化的部署过程。将部署自动化有助于减少在“完成”软件和实现其价值之间突然出现的摩擦和延迟。Dave Farley和Jez Humble正在完成一本关于这个话题的书持续交付。它建立在许多通常与持续集成，驾驶更加朝着这个能力迅速投入到软件生产和得到它做的事情。他们在蓝绿色的部署部分引起了我的眼睛为多数民众赞成未被充分利用这些技术中的一种，所以我想我会在这里给它的一个简要概述。

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

综合监视(也称为语义监视)定期针对实时生产系统运行应用程序自动化测试的子集。结果被推入监视服务，在出现故障时触发警报。这种技术结合了自动化测试和监视，以检测生产中失败的业务需求。

观测我们的软件系统一直是有价值的，并已在这个时代的云和微服务的更加如此。然而，我们加入到我们的系统中可观测往往是在自然界中相当低的水平和技术，而且往往似乎需要乱扔我们的代码库与这些混沌，详细呼叫记录不同，仪器仪表和分析框架。本文介绍了清理这个烂摊子，使我们能够在一个干净的，可测试的方法添加与业务相关的可观察的模式。

金丝雀释放是一种降低在生产中引入新软件版本的风险的技术，方法是在将更改推广到整个基础设施并让每个人都可以使用之前，缓慢地将更改推广到一小部分用户。

我最喜欢的soundbites的是：如果疼，就多做。它看似荒谬的表面上，而是产生一些有价值意义的快乐属性，当你深入挖掘

暗启动一个特性意味着采用一个新的或更改后的后端行为，并在用户不知道被调用的情况下从现有用户那里调用它。这样做是为了在公开发布新功能之前评估额外的负载和对系统的性能影响。

软件开发团队发现，如果他们尽可能频繁地集成他们的工作，生活会变得容易得多。他们还发现经常发布到生产环境中很有价值。但是团队不希望向他们的用户公开半开发的特性。处理这种紧张关系的一种有用的技术是构建所有后端代码，进行集成，但不构建用户界面。功能可以被集成和测试，但是UI会被保留到最后，直到它被添加来完成功能，并向用户展示它。

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

粉丝们普遍认为的一个假设持续集成问题是构建应该是可重复的。我们的意思是，在任何时候，您都应该能够使用您正在使用的系统的某个旧版本，并按照与您当时所做的完全相同的方式从源代码构建它。

现代应用程序服务器的一个oft宣传的特性是它们在集群中提供故障转移。集群可以提高应用程序的可靠性，如果一个服务器宕机，还可以为客户提供更多的服务器。故障转移可以增加更多的可靠性，如果一台服务器在交互过程中出现故障，集群可以将该交互转移到另一台服务器。

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

基础设施即代码是通过源代码定义计算和网络基础设施的方法，这些源代码可以像任何软件系统一样处理。这样的代码可以保存在源代码控制中，以允许可审核性ReproducibleBuilds，受测试实践，和完整的规程ContinuousDelivery。在过去的十年里，这是一种处理增长问题的方法CloudComputing并将成为未来处理计算基础设施的主要方式。

自动化配置工具(例如Cfengine的，木偶， 要么厨师)让你避免SnowflakeServers通过提供菜谱来描述服务器元素的配置。在服务器实例的整个生命周期中，配置同步不断地将这些规范应用到服务器实例上，要么按照常规计划，要么在其发生更改时。如果有人在工具之外对服务器进行了更改，那么在下一次同步服务器时，该更改将恢复到集中指定的配置。如果需要进行一些配置更改，则在配置规范(菜谱、清单或特定配置工具所调用的任何内容)中进行更改，然后应用于基础设施中的所有相关服务器。

自动化配置工具(例如Cfengine的，木偶， 要么厨师)允许您指定应该如何配置服务器，并使新的和现有的机器符合规定。这有助于避免脆弱的问题SnowflakeServers。这些工具可以创建PhoenixServers可以随意拆除和重建。不可变服务器是这种方法的逻辑结论，服务器一旦部署，就永远不会被修改，只是用一个新的更新的实例替换。

在过去的几年里，“云”已经成为一个非常夸张的术语。过度炒作的词的一个特点是它们几乎没有定义(是的NosqlDefinition我正看着你)。

事实证明有云的计算可用的优异的清晰度，从没有其它说NIST。这本书非常简短易懂标准文件(不，我不是在开玩笑)。

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

这样就形成了独一无二的雪花——对滑雪场来说是好事，对数据中心来说则是坏事。

有一天，我不得不开始对操作的认证服务的幻想。该认证评估将包括一个同事和我在企业数据中心转动起来，并着手用棒球棒，电锯和水枪关键生产服务器。评估将基于它需要多长时间的运营团队把所有的应用程序并再次运行。