在2015大会上提出，尽管在过去的时间里软件开发尚未达到最佳的水平，但当前的研究正表明持续交付的实行会带来重大的改进。Farley说，给软件开发经济模式带来了改变，使大家可以更迅速地验证商业思路，并降低了缺陷率，当故障发生时也可以更加快速地恢复服务。

Farley在讨论中展开讨论了“软件开发在过去的时间里尚未达到最佳的水平”，他引用了KPMG和Logica发布的一系列，以及麦肯锡的质量统计报告。在过去的20多年里，软件行业一直在努力改进开发方法论，其中包括将顺序的方式（比如）换成更加迭代化的过程（比如），但是Farley提出，我们却未能从根本性错误中汲取到教训。

软件交付的根本目的是为客户提供一个产品，为其验证商业思路，最后为最终用户提供价值。在客户和商业之间反馈是必不可少的，迭代过程一定要执行得快速、廉价、可靠。

Farley提出，科学和科学的方法是人类最伟大的发明。在软件交付中，实现快速的反馈周期是这种科学方法的关键。Farley说，科学方法的基本步骤包括描述问题、形成假设、推理论证和校验求证。

\

描述 - 基于经验和观察进行猜测。

\\

假设 - 提出一种解释。

\\

推导 - 对假设进行预测。

\\

实验 - 对推导进行试验。

\\

重复！

\

Farley接着说的原则（比如“一体化质量”、“寻求整体最佳”和“增强了解”）能够大幅缩短软件交付的周期。Farley举了一个传统软件开发方法的例子，它的交付周期有103天，我们再来看看换成精益的持续交付方法，交付周期只有57分钟。短的周期时间使商业理念得以快速地验证，从而改变了软件交付的经济模式。如果系统引入了缺陷，快速的周期可以缩短MTTR（修复前平均时间），因为较短的周期会更易于推断出要做哪些修改。

Farley引用敏捷软件开发宣言的第一准则强调了持续交付的重要性，“我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户”，并用一连串陈述句完整地定义了持续交付的概念：

\

敏捷宣言的第一准则。

\\

持续集成的逻辑延伸。

\\

着眼全局看开发。

\\

每次提交创造一个候选版本。

\\

发到生产环境中才意味着结束！

\

Farley说，持续交付的核心原则包括创建一个可重复的、可靠的软件发布流程，保持每件事都在版本控制之下，一体化质量，重新定义“完成”就表示已经发布了，使每个人都对发布流程负责，实行持续的改进。

这个核心原则应包含在部署流程的实现内，它的目的是使“开发人员提交了代码”就意味着这些修改是为客户价值的提供，是针对任何会给生产环境带来问题的变更的检测和预防。应支持各类组织间涉及到软件交付的工作协作，让每个人都能够看到系统内与流程相关的变更。

Farley说，常常会有一系列反对组织内部实施持续交付的论点。第一个证据是，“持续交付只适合小型的项目，它不可能用于大型的项目”，看看谷歌的构建过程这个论点就不攻自破了。谷歌主要使用一个单独整体的代码库，针对每次提交运行持续构建和测试，这个库中有超过1亿行代码，每年有6千多万次的构建。

第二个论点是，“这风险太高了，发布始终是造成灾难的因素”，让我们看看亚马逊构建过程就可以回击这个论点。Farley说2006到2011年间，在亚马逊上实现的持续交付将部署导致的运行中断降低了75%，将部署导致的运行中断分钟数降低了90%。

最后一个反对实施持续交付的论点是这么说的，“这种方式合适简单的网站，但我的技术太复杂了”。Farley用惠普的故事进行了反驳，惠普转换了所有产品开发方法，这是一个大型的、复杂的、基于硬件的项目，具有多个产品并历时4年。实施持续交付后开发人员生产力得到了10倍的增长。

Farley最后的结论是实施持续交付会对商业产生积极的影响，并提出“持续交付改变软件交付的经济模式”。Farley引用了企业管理协会（EMA）“DevOps和持续交付”2014年度报告大会的数据，有87%具有开发和运维职能的公司收入增长被评为“卓越的”，它们比2013年至少有10%的收入增长，与此相反，只有13%具有开发和运维职能的公司被评为只取得“普通的”或者是更糟的增长。

Farley引用了Puppet实验室的“报告”，说明持续交付促成更高的生产能力和更高的可靠性，故障发生时的12次服务都得到更加快速的恢复。Farley再次引用Puppet实验室报告，说组织文化是IT性能和组织整体性能最重要的预测因子。

\

我们现在可以信心十足地断言，高的IT性能与强劲的经营业绩是分不开的，它有助于生产力、赢利能力和市场占有率的提升。

\

Dave Farley演讲的幻灯片可以在伦敦QCon 2015大会网站日程页上找到，可点击“”下载。

查看英文原文：