借助持续交付改善 IT 绩效

降低发布风险，是持续交付最主要的收益；完善的自动化测试和持续集成则是能对 IT 绩效产生最大影响的实践。针对持续交付和 IT 绩效的研究发现，持续交付实践的实现有助于改善 IT 绩效，更高的绩效可进一步实现更快的节奏和更高的稳定性。这是 Jez Humble 的主张。

Jez Humble 将在 Lean IT Summit 2017 大会中介绍持续交付的实现，InfoQ 会通过问答、总结报道和相关文档对本次大会进行报道。

Lean IT Summit 2017 大会将于 3 月 14-15 日在法国巴黎举行：

Lean IT（精益 IT）提供了已获证实的管理实践，可以帮助我们顺利应对数字化趋势为工作环境造成的很多挑战。本次会议将探讨精益 IT/ 数字化能为我们带来的下列三类价值：

• 满足客户和用户需求；
• 加快获得竞争优势的速度和敏捷度；
• 帮助组织摆脱泰勒主义（Taylorism）的局限，与客户、员工和供应商建立更紧密的合作关系。

InfoQ 就持续交付与 IT 绩效之间的关系，采用持续交付方法的组织所能获得的收益，以及持续交付实践对绩效的影响等问题采访了对此有深入研究的 Jez Humble，并请他对希望应用持续交付实践的组织提出了自己的建议。

InfoQ：您为什么决定研究持续交付与 IT 绩效之间的关系？

Jez Humble：自从 2010 年，市面上开始出现有关持续交付的书籍开始，有关这种方式能否成为主流就引发了非常多的争议，甚至在大型金融服务公司和政府中也是如此。然而我希望了解这种方法中最重要的部分是什么，为什么会如此重要，并希望尝试构建一种能够帮助他人了该方法所提供收益的定量框架。我与业务合作伙伴Nicole Forsgren 博士以及Gene Kim 有关 DevOps 研究和评估做所的工作，以及与 Puppet 团队的合作成果已经远远超出了我最开始就已非常“狂妄”的预期。

我们发现了一种通过统计学验证有效的 IT 绩效建模方法，通过该方法可以确定，持续交付实践的实现确实可以改善 IT 绩效，而更高绩效有助于改善速度（以发布频率和前置时间来衡量）和稳定性程度。

InfoQ：组织通过应用持续交付，都能获得哪些收益？

Humble：正如在我自己的持续交付网站上提到的，持续交付最主要的收益以及最初的驱动力是降低发布风险。Dave Farley 和我写了一本书，当时最大的目标之一是帮助大家能够在正常业务时间内为复杂的企业级系统发布新版本，从而避免执行复杂的，需要繁琐的编排，（通常需要）手工进行，并且因为需要停机，只能在夜间和周末进行的发布工作。

然而同样的技术也能提高软件质量，加快上市速度，提高发布频率，降低持续不断的交付成本。通过大幅降变更推送所产生的事务成本，我们改变了软件交付过程的经济影响，使其更适合通过小批次的推送来实现。因此持续交付的基本原则和实践也成为很多精益创业（Lean startup）技术主张的前提条件，例如 A/B 测试和快速交付，以及根据用户反馈进行快速的 MVP 演进。

也许最有趣的是，我们的研究发现持续交付有助于消除职业倦怠，让团队成员更快乐，并能改良组织文化。但这也并不是万灵药，持续交付需要进行巨大的投入，只适合需要在生命周期内进行大幅革新的产品和服务。

InfoQ：哪种持续交付实践能对 IT 绩效造成最大影响？

Humble：全面的自动化测试和持续集成的影响是最大的，对代码和基础架构进行版本控制的影响略小，但依然很重要。持续交付还能对 IT 绩效产生巨大影响，几乎可以解释大约 1/3 的方差。

然而这些技术实践需要进行投入，就算到现在已经有了超过 15 年的历史，并且起到了极为重要的作用，但依然有很多团队没有运用极限编程（Extreme Programming）方法。很多组织依然没有为自己的关键业务服务提供可靠、全面、可维护的自动化测试。很多据称在实践持续集成的团队，其实根本没有这样做。我通过一个测试来了解人们是否真的才用了持续集成方法：开发者是否以至少每天一次的频率将代码推送至共享的 Trunk/master？每次提交能否触发运行自动化的构建和测试？如果构建失败，通常能否在十分钟里修复？很多人对所有这三个问题都无法给出肯定的答案。持续集成和自动化测试是很难，需要大量投入，但通过数据可以很清楚地看到，这些技术能对软件交付绩效起到巨大的促进作用。

InfoQ：是否有什么实践只有很小的影响，甚至全无影响？对于这种情况，我们知道具体原因吗？

Humble：我们发现由开发团队之外的人员负责对变更进行审批，这种做法会极大降低速度，甚至会对稳定性产生不利影响。相比来说，诸如结对编程（Pair programming）和代码审阅（Code review）这样的内部审批流程往往更有效。对此我们的猜想是：很难通过检查了解代码变更所能产生的影响。而在风险管理方面，使用自动化测试，辅以轻量级跨团队审批流程，往往能获得更好的效果。

很多人可能还会对另一件事感到惊奇：QA 主导创建和维护的接受性测试（Acceptance test）和 IT 绩效之间没有直接关系。这种事最好让开发者自己进行，或者至少要让开发者与测试人员进行合作。对此我们的猜想是：如果开发者参与到自动化测试的创建和维护过程中，就能产生一种让软件更加“可测试”的力量，进而让测试工作更可靠。我的个人体验是：如果开发者没有参与自动化测试，最终的测试将需要极为高昂的维护成本，并且会更频繁地失败，因为开发者对此并不关心。

InfoQ：对于希望应用持续交付方法的组织，您有何建议？

Humble：持续交付是一个漫长的旅途，而非终点，其本质在于持续不断的改进。首先可以从定义并探讨所要实现的，可度量的业务目标开始，随后要确保团队具备最终获得成功所需的时间和资源。如果要实现更完善的交付，通常需要在自动化测试和开发方面进行巨大的投入，甚至可能需要对构建系统进行重构，借此让开发者能在自己的工作站上更轻松地进行测试，并用一种更简单的方式进行开发，而不需要进行（假设来说）大量的编排工作。这一切都需要充分的准备。Amazon 用了四年才从原本的单体（Monolithic）架构过渡至持续部署所需的面向服务的架构。

然而对于持续交付，最棒的地方在于，很多情况下不需要太多工作就能在本地实现非常显著的改进。我对于持续交付最早的体验始于 2005 年，当时我与一个人数并不很多的团队合作，希望对一个大型应用程序的部署实现自动化，经过我们的努力，原本需要数天的部署工作被缩短至不到一小时，停机时间缩短至不到一秒，并能使用蓝 / 绿部署模式在不到一秒的时间里实现全自动的回滚。我们只用了几个月就实现了这样的成就，所有这一切都是通过 Bash 和 CVS 做到的。这就让我产生了另一个观点：人们会趋向于过度关注所用的工具。远离糟糕的工具，这一点固然重要，但市面上有那么多好的（甚至免费的！）工具，你更不能将大量时间和精力用来争论到底哪个工具才是最好的。你应该专注于架构和文化本身。

查看英文原文： Improving IT Performance with Continuous Delivery