这篇开始进入第五章的学习，第五章主要讲的就是Continuous Delivery，简称CD，翻译就是持续交付。在DevOps中CI和CD是两个经常被提起的话题，在你以后工作中，经常要遇到这两个单词。第五章，你就明白什么是CI 什么是CD。
你无法绕过DevOps，如果没有关于持续集成和持续交付的大量讨论。在这一篇文章，我们将介绍五大优势。在旧的交付软件方式中，在开发过程中花费的大部分时间内，应用程序无需运行，至少不是整体运行。您只需构建和部署应用程序，并在最后将其提交到测试阶段。在项目后期大批量获取错误报告。但是，在持续交付中，你有一个应用程序，可以自动构建每个代码提交（PS，类似Jenkins的工具）。
每次持续交付，运行单元测试，并将应用程序部署到类似生产的环境中。此外，还会运行自动验收测试，并且在更改后，要么通过测试或者失败，当代码check in进来后，只需要几分钟时间就可以完成单元测试。现在有些定义是这样描述：持续集成是经常自动构建和单元测试整个应用程序的实践过程。理想情况下，在每个源代码上check in，持续交付是将每个更改部署到类似环境的生产，并执行自动集成和验收测试的附加实践。
持续部署将此扩展到每个变更都经过充分自动化测试的地方。它被自动部署到生产环境中。 Facebook，Etsy和Wealthfront等大型网络都在使用持续部署。使用这些技术的最令人信服的原因之一是将产品推向市场所需的时间大大减少。2016年DevOps状态报告发现，与同行相比，高性能IT组织可以按需部署，需要数天，数周或数月。
高绩效的IT组织能够快速从概念转向现金。允许快速实验和市场验证。我们现在看到组织每天部署一个给定的应用程序十次，甚至几百次。您可能会认为快速周期和高频率的变化会让您看到质量下降，但实际情况恰恰相反。 是的，DevOps状态报告还发现，这些高绩效组织的变更失败率比同行低三倍。
这种质量的提高发生了，因为我们不是在开发生命周期结束时进行检查，而是在交付管道中更早地集成测试。我们逐个评估和部署更改，而不是由数百个更改组成的大型实体。测试每次提交，并确保软件处于运行状态。你知道，Lean（一个精益模型）告诉我们，正在进行的高水平工作，换句话说，一次全部部署到生产环境的大数量任务，确实非常危险。持续集成的一个备受争议但重要的原则是，开发人员必须在Master或Trunk之外工作。（PS代码分支的概念，可以了解一下）
DevOps状态调查的一个有趣发现是，在合并到Trunk之前，拥有非常短的生命周期（不到一天）的分支或分叉，总共少于三个活动分支，都有助于提高性能。 是的，简而言之，我们缩减了与正在进行的工作相当的软件集成更改量。对我来说，当我阅读Jez Humble关于持续交付的书时，所有这些都真的被点击了。它提出了一个批量大小。从这本书中思考的一句话是“这不是你能提供多少，而是多少。” DevOps状态报告还说，高绩效IT组织提到，将更改部署到生产中所需的准备时间不到一小时。
低绩效者需要一到六个月的交货时间。我的意思是这是一个巨大的，巨大的竞争优势。你能从多久从失败状态中恢复？关于在持续交付环境中工作的有趣部分是有两个向量，使您的平均恢复时间更短。首先，一旦你处于失败状态并且你已经提出了补救措施，它就可以像任何其他变化一样对待并快速推出，而不会破坏你的常规过程。第二个也是不太明显的好处是使用持续交付来找出失败的原因。例如，在我的工作中，我们在几天的时间内数据库连接增长缓慢。它一直在增长，直到我们达到极限，一切都破裂了。通过将连接增长图与同一时间窗口中发生的部署重叠，我可以快速确定哪个提交引入了错误。在我之前的工作中，同样的练习花费了数周时间，因为这一变化发生在季度发布中，同时发生了数百次变更。对我而言，这证明持续交付实际上减少了MTTR，并且具有巨大的运维影响。在接下来的部分中，我们将讨论持续集成，以及每个应该存在的持续交付管道（Pipeline）和实践。
这篇的，大概了解了一下什么是持续交付和持续集成的概念。持续交付就是这么具体例子去理解。加入要给银行外包一个软件项目给一个外包公司。传统软件交付是，半年或者一年之后交付。如果使用DevOps的文化，进行持续交付，半个月交付给银行一次甚至一个礼拜一次。这样半年或者一年中需要做几百次的持续交付。持续交付离不开持续集成，下一篇介绍持续集成。所以，我们鼓励，代码变更小的运维部署加上快速的部署时间，这种的方式是最优的软件交付方法。