别让持续交付自动化交付bug

你的连续交付能力用得还好吗，比如频繁发布移动或云应用的特性增强？还是恰好相反，快速发布了带漏洞的版本？ - Joel Shore

---

连续交付能让交付流程跑得更快，但连续交付本身并不能为发布质量打包票。国外基于Jenkins持续集成和连续交付平台的某应用交付技术提供商认为，如果发布质量没有得到一定程度上的保障，软件交付的快点慢点都没有太大意义。

随着DevOps兴起以及新时代下的行业竞争日趋白热化，敏捷开发和交付速度渐渐跑到能力新高峰，但大家仍越来越需要更快速交付高质量软件。位于加州的一个软件公司CEO Sacha Labourey在接受我们专访时谈到了应用交付的新发展以及他的担忧。

云和移动应用是怎么样改变着连续软件持续交付的规则？
Sacha Labourey：我们正经历一段有趣的时光。我们认为IT行业应当需要加快开发和交付周期，来顺应这个时代的要求。移动应用开发中，DevOps能让你从故障发现和快速失败中受益匪浅。云应用同理，它们都实现了发现过程和利用资源加速交付的能力。

你认为DevOps扮演着重要角色吗？
Labourey：我们在很多组织中发现，许多公司并非被迫投入去做DevOps或持续集成。大家都认为移动需求大就做了移动应用，云需求大就做了云功能。问题是企业得学会预见技术竞争战场，清楚怎么样才能快速改变和建立最佳实践。也只有产生了类似念头的时候，他们才会意识到当下要做的事已不同往昔那样随波逐流。我们与很多开发团队和DevOps团队讨论过，以便帮助普通企业能寻求到一些突破。讨论结果大致是这样：DevOps已经不单是IT系统在效率上的提升问题，而涉及到了将企业发展目标纳入应用开发和交付的过程。许多企业仍然对这些变化视而不见，但转型已经开始，避无可避，且势不可挡。

DevOps团队软件持续交付方面最常见的错误是什么？
Labourey：不劳而获想解决困难才是最常见的错误。即使是新开的项目，也会面对一些已知或未知的难题。代码自动化构建实现起来很容易，难的是对项目做出恰到好处的测试、配置、部署，而想做到这些，就需要DevOps团队投入。当团队没有决心做好这件事，结局就是得到一个被戏称为“发布bug颇有效率的过程”。

这么说，那岂不是持续交付软件产品，在某种情况下就是为了更快地发布bug？
Labourey：小步快跑的发展节奏没有问题。我们讨论业务节奏加快的可行性需要在速度与稳定安全找到个平衡点。改变迭代速度并不是说你写代码的速度一下子就提高了，这个要适可而止，换个说法：“更接近预期的安全速度”，这种描述可能更适合，对吧？以更短周期做出新版，看看哪些起作用，哪些不起作用，然后再决定具体的迭代方式。

软件持续交付怎样与DevOps在总体上做到互相配合？
Labourey：首先，DevOps是一条好路子。原先那帮支持DevOps和敏捷开发的人都应该自豪，这点让人想起了上世纪90年代的开源思潮。不过，那时候的那群人基本都是不care企业生产概念的理想主义者。
就像Linux甚至今天的Microsoft，这些都彰显着开源世界的胜利。开发方法论也是这样。以前的发布周期都很长——都要好几年。在21世纪初，敏捷开发那帮人根本感受不到关键软件对在生产过程中运行关键应用的意义。当下，如果你没有最起码的敏捷开发或更进一步的团队DevOps规划，你就是迟到了，毕竟每家公司都应该懂得从软件生产中创造商业价值。

你怎么向不了解DevOps持续交付的开发人员安利这些道理？
Labourey：显然，如果你还没有移动化应用的持续交付流程，那这本身就是个bug…如果有针对云平台的软件持续交付过程就更好了。你有弹性资源，有平稳的软件更新能力，甚至还有实现云端软件交付的成熟方式，这些能力如果放着不用，那简直太不明智了。这个有点像很多上云的公司只把云当作自己的数据中心，这就有点大材小用了。