ACM通信

频繁的发布改变了软件工程

软件发布周期通常很长，以月为单位，有时以年为单位。每个阶段——需求、设计、开发、测试——都需要时间。

最近，对软件部署的一些约束发生了变化。在web软件中，部署到您自己的服务器，几乎立即和高度可靠。在桌面上，我们的许多应用程序现在例行地检查每次使用的更新和补丁本身。向人们发布新软件不再是缓慢和不一致的情况。在大多数机器上可能有可靠、快速的互联网连接，这使得频繁部署软件成为可能。

但是，仅仅因为一件事是可能的并不意味着它是可取的。为什么我们要更频繁地部署软件?对改变谨慎、缓慢和深思熟虑不是更好吗?

考虑频繁部署的主要原因不是将软件更快地交付给客户的直接影响，而是内部的间接影响。频繁的发布迫使组织改变开发软件的方式。这些变更最终降低了风险，加快了开发，并改进了产品。

例如，考虑每天多次部署软件需要什么。首先，您需要构建新的部署工具，这些工具能够快速推出新软件，能够处理数千个潜在版本并强制一致性，并允许在出现问题时快速回滚。

软件开发必须改变。由于多个几乎同时推出的版本，无法保证同步部署，且无法与其他更改进行协调，因此所有软件更改都必须是独立和向后兼容的。软件必须不断发展。

需求、设计和测试可以被缩短并替换为在线实验。要了解更多关于客户需求和设计偏好的信息，可以对一小部分客户进行部署，针对更大的控制组进行测试，并获得关于人们想要什么的真实数据。通过小型部署、部分部署和快速回滚，可以预期bug并将其作为风险进行管理。

将其与更传统的开发过程进行比较。需求收集和设计是基于少量的用户研究和少量的数据。软件的开发不考虑向后兼容性，必须与许多其他更改同步推出。测试的目标是消除bug，而不仅仅是管理风险，而且是漫长而昂贵的。当软件推出时，我们不可避免地会在需求、设计和测试中发现错误，但是组织没有内在的能力通过快速回滚问题或推出修复程序来做出响应。

频繁发布是需要的，因为它在软件工程中强制进行更改。它不鼓励高风险、昂贵的大型项目。它鼓励实验、创新和快速迭代。它降低了失败的成本，同时也最小化了失败的风险。这是构建软件的一种更好的方法。

对软件部署的约束已经改变。我们关于软件部署的成本、一致性和速度的旧假设不再成立。是时候重新思考我们如何进行软件工程了。

没有发现记录