Timothy Fitz的博文 持续部署,在Dave和我关于持续交付的书一年前就有了。那么,我们为什么选择一个不同的名字呢?它们确实是有差别或是因为我们故意作对?

我们给书起名持续交付基于以下几个原因。首先,有些学究气的说,部署没有隐含发布的意思。正如我们在书中说,你可以不断地部署到UAT(用户验收测试) - 没什么大不了的。持续部署特别之处是把通过自动测试(或者加上简短的QA测试关)每个改变部署到产品。持续部署是把每一个好的构建版本发布给用户的做法 - 准确点可以说是“持续发布”。

持续部署意味着持续交付,反之则不然。持续交付是是由商业来控制发布时间表,而不是IT。实现持续交付意味要确保软件在其整个生命周期始终可以作为正式产品发布 - 在某刻按下按钮,经过一个完全自动化的过程,在几秒或几分钟后,任何构建版本都有可能发布给用户。

这反过来又依赖于综合自动化的构建,测试和部署流程,和参与交付人员的优秀合作 - 开发人员,测试人员,数据库管理员,系统管理员,用户,业务人员。

在持续交付的世界里,如果仅仅是把代码交给测试人员,或者QA测试通过,开发者不能说这个功能已完成,只有在产品中正常工作才能说完成。这意味着没有更多的测试或部署阶段,即使是在Sprint中(如果你使用Scrum)。如果你在使用看板,而且想要持续交付,那么直到你的工作发布给用户后,你才能增加一个新故事。

发布每一个好的构建版本给用户并不总是有意义的。在特殊情况下是不可能做到的,比如嵌入式产品中同时牵扯到软件和硬件的变化。在COTS(商用现成产品)世界中,有充足的营销和技术支持方面理由说明在产品周期任何时间内不能有好几个以上“发布版本”(尽管你可以像Eclipse和Onmi Group那样做定期的“开发版本”或“早期版本”)。可能还有其他充分的理由 - 重要的一点是,这些都是商业上的理由。

那怎样才算在做持续交付?我建议是,如果你决定这是向客户提供价值的最佳途径,就可以切换到持续部署。特别的是,如果不能发布每一个良好的构建版本给用户,怎样才算故事完成?我认为至少适用于以下几个条件:

  • 对包含整个故事的构建版本必须运行完整测试套件。这证实了这个故事交付了预期的商业价值,在开发过程中也没有退化。为了高效率,这意味着在单元,组件和可接受的层级进行综合自动测试。

  • 这个故事已在类产品环境中证明给客户。类产品环境意味着在情理之内等同于真实产品环境。即使你在部署一个巨大的集群,可以使用一个像蓝绿色的部署技术,在不影响用户的情况下,在生产环境中同时运行应用程序的不同版本。

  • 没有部署到产品的障碍,换句话说,如果你决定了,就可以在按下一个按钮后使用一个完全自动化的过程部署一个版本给用户。特别是,这意味着你还进行了了跨功能角色的测试,如容量,可用性和安全性。如果你正在使用SOA,或者您的应用程序和其他系统之间有依赖关系,这意味着要确保整合没有问题。

Jetz August 13th, 2010 原文在此