DevOps之持续交付

持续交付

持续交付是一种可以帮助团队以更短的周期交付软件的方法，该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

通过对生产环境中的应用程序进行更高频次的增量更新，这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。

注意：持续交付 ≠ 持续部署 - 有时候很多人会把持续交付误认为成持续部署。持续部署是指每个变更可以自动部署到生产环境。持续交付是指团队确保每个变更可以部署至生产环境，但也许并不需要实际部署，这通常可能是出于业务方面的原因。只有成功实现持续交付的前提下，才能进行持续部署。

持续交付的主要想法在于：

• 部署越频繁，对部署流程就会越熟悉，自动化机制就能获得更好的结果。如果同一件事每天需要执行3次，很快你将变的无比娴熟，但很快也会因为日复一日解决同样的问题而感到厌烦。
• 部署越频繁，所部属的变更集就越微不足道，而这些微不足道的内容最有可能出错，甚至可能导致丢失对整个变更集的控制力。
• 部署越频繁，TTR（修复／解决所需时间）指标就会越出色，从业务用户处获得有关功能的各类反馈的速度越快，作出改进以便完美满足对方需求的过程也会越简单（这方面TTR与TTM其实非常相似）。

（来源：Ops Meta-Metrics: The Currency You Pay For Change ）

但持续交付并不仅仅是尽可能频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践：

• 从实践中学习
• 自动化
• 更频繁的部署

3.1 从实践中学习

持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中，而在于业务用户中。然而无论花多长时间，没人能真正清楚地表达自己的想法，或者将自己的想法用清晰的文档概括出来。也正是因此，敏捷方法论强调将功能提供给用户，并不惜一切代价从用户处获得尽可能多的反馈。

持续交付与持续部署类似，需要尽可能减少前置时间，这也是尽快从用户处获得“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。我们绝不能尽信自己的用户或寄希望于通过正规形式的反馈了解用户。我们只能相信自己的度量。

痴迷于度量是精益创业（Lean Startup）活动中一个重要的概念，但这一概念对DevOps同样重要。我们应该度量一切！确定最恰当的度量指标可以让团队了解某种方法最终能否成功或失败，了解怎样做可以获得更好的结果，以及哪些最成功的做法同时也蕴含着一定的风险。为了帮助团队做出更明智的决策，在确定要衡量的指标时，一定要抱着“宁多勿少”的原则。

不需要“考虑”，只需要“知道”！“知道”的唯一方法就是度量，度量一切：响应时间、用户思考时间、展示次数、API调用次数、点击率等，但这些并非需要度量的全部。找出所有能让你更进一步了解用户对功能看法的度量指标，对所有这些指标进行度量！

这种方法可以表示为如下形式：

3.2 自动化

自动化已经在上文

2. 基础架构即代码

在这里我想强调的是，在没有将与基础架构有关的所有供应和任务实现妥善、全面的自动化之前，持续交付根本无从谈起。

这一点很重要，因此有必要再重复一遍：环境的搭建和生产就绪版本软件的部署只需要一键点击，只需要运行一条命令，整个过程应该自动完成。否则根本无法设想能一天多次部署同一个软件。

在下文的

3.5 零停机部署

3.3 更频繁的部署

DevOps的信条在于：

“越是困难的事，需要更频繁地进行！”

敏捷思维中，困难任务更要迎难而上，更频繁地去做，这中想法非常重要。

自动化测试、重构、数据库迁移、面向客户的产品规格、规划、发布 - 所有这些活动都要尽可能频繁地进行。

原因主要有三点：

1. 首先，随着要做的工作量逐渐增加，这些任务也会变的愈加困难，但如果能拆解为小块，则会变的相对容易些。

   以数据库迁移为例：一些涉及大量表的大规模数据库迁移工作很麻烦，容易出错。但如果一次只迁移一部分，则可以相对较容易地成功完成整个迁移任务。此外还可以轻松地将多个小规模的迁移任务安排成一定的序列，在将一个艰难的大任务拆解为一系列容易实现的小目标后，处理起来就简单多了。（这也是数据库重构的本质）

2. 第二个原因在于反馈。大部分敏捷思维关注的是设置反馈环路，借此让我们更快速地学习了解。反馈已经是极限编程（Extreme Programming）中一个非常重要，蕴含巨大价值的概念。在诸如软件开发等复杂流程中，我们需要更频繁地检查自己的最新进展，并进行必要的纠正。为此我们必须尽一切可能创建反馈环路，并提高反馈的频率，这样才能更快速地酌情做出调整。
3. 第三个原因是实践。对于任何活动，越频繁地从事就越能获得完善。实践可以帮助我们理清整个流程，让我们更熟悉代表有事情出错的征兆。只要认真琢磨自己从事的工作，就能提炼出近一步完善所需的实践。

   对于软件开发，也有可能实现一定程度的自动化。一旦有人将某件事做了多次，就可以更容易地确定该如何进行自动化，更重要的是，这样的人在对这些事情实现自动化方面将有更大的动机。此时自动化尤为重要，因为可以加快速度并降低出错的概率。

那么这就产生了一个问题：使用DevOps方法时，该选择怎样的交付频率？

这个问题没有标准答案，而是取决于产品、团队、市场、公司、用户、运维需求等各种因素。

我认为最佳答案应该是：如果不能实现至少每两周一次交付，或在冲刺阶段结束时交付，那么连敏捷都谈不上，DevOps又从何谈起呢？

DevOps鼓励我们尽可能频繁的交付。在我看来，你需要对团队进行培训，让他们能够做到尽可能频繁的交付。我在我的团队中使用的一种较为可行的方法是在QA环境中每天交付两次。交付过程是完全自动化的：每天两次，中午和午夜各一次，计算机启动起来，构建软件组件，运行集成测试，构建并启动虚拟机，部署软件组件，对其进行配置，运行功能测试等。

3.4 持续交付的前提需求

在改为使用持续交付方式之前，需要满足哪些要求？

我草拟的需求清单如下：

• 对软件组件的开发和平台的供应和设置进行持续集成。
• TDD - 测试驱动的开发。这一点还有待商榷……但始终还是需要面对：TDD是目前唯一能通过单元测试对代码和分支进行可接受程度覆盖的方法（单元测试使得问题的修复过程比集成测试或功能测试容易很多）。
• 代码审阅！至少要进行代码审阅……如果能进行结对编程（Pair programming）当然就更好了。
• 软件的持续审计 - 例如使用Sonar。
• 在生产级环境实现功能测试的自动化。
• 更强大的非功能测试自动化（性能、可用性等）。
• 独立于目标环境的自动化打包和部署。

另外在管理重大功能和演进时，还需要具备健全的软件开发实践，例如零停机部署技术。