持续交付

2013年5月30日

持续交付是一种软件开发原则,即以始终可以将软件发布到生产环境的方式构建软件。

在以下情况下,您正在进行持续交付:[1]

  • 您的软件在其整个生命周期中都是可部署的
  • 与开发新功能相比,您的团队优先考虑保持软件的可部署性
  • 任何人在对系统进行更改时,都可以随时获得有关其生产准备情况的快速、自动反馈
  • 您可以按需将任何版本软件一键部署到任何环境

您通过持续集成开发团队完成的软件、构建可执行文件并在这些可执行文件上运行自动化测试以检测问题来实现持续交付。此外,您将可执行文件推送到越来越接近生产环境的环境中,以确保软件能够在生产环境中正常运行。为此,您可以使用部署流水线

关键测试是,业务负责人可以要求立即将当前开发版本的软件部署到生产环境中,而没有人会感到惊讶,更不用说恐慌了。

要实现持续交付,您需要

  • 参与交付的每个人之间紧密、协作的工作关系(通常称为DevOps 文化[2])。
  • 对交付过程的所有可能部分进行广泛的自动化,通常使用部署流水线

持续交付有时会被误认为是持续部署。持续部署意味着每个更改都会经过流水线并自动投入生产,从而导致每天进行多次生产部署。持续交付只是意味着您可以进行频繁的部署,但可以选择不这样做,这通常是因为企业更喜欢较慢的部署速度。为了进行持续部署,您必须进行持续交付。

Jez HumbleDave Farley 合著的书是关于此主题的基础书籍

持续集成通常是指在开发环境中集成、构建和测试代码。持续交付在此基础上构建,处理生产部署所需的最后阶段。

持续交付的主要好处是

  • 降低部署风险: 由于您部署的更改较小,因此出错的可能性较小,并且如果出现问题也更容易修复。
  • 可信的进度: 许多人通过跟踪已完成的工作来跟踪进度。如果“完成”意味着“开发人员宣布它已完成”,那么这远不如将其部署到生产(或类似生产)环境中可信。
  • 用户反馈: 任何软件工作面临的最大风险是,您最终构建了一些无用的东西。您越早、越频繁地将工作软件交付给真实用户,您就越快地获得反馈,以了解它的真正价值(特别是当您使用观察到的需求时)。

用户反馈确实要求您进行持续部署。如果您想要这样做,但又不想将新软件提供给所有用户,则可以部署给一部分用户。在我们最近的一个项目中,一家零售商首先将其新的在线系统部署给了其员工,然后部署给了受邀的一组高级客户,最后部署给了所有客户。

延伸阅读

有关更多信息,最佳在线资源是 Jez Humble 的持续交付页面。(特别是Jez 解释了为什么他和 Dave Farley 选择了“持续交付”这个名称,并将其与持续部署进行了对比。)有关更多详细信息,您应该阅读这本书。我还列出了一些资源在我的指南页面上。

致谢

Jez Humble 为此页面提供了详细的帮助。

注释

1: 这些指标由 Thoughtworks 的持续交付工作组制定

2: 尽管名称为“DevOps”,但这应该扩展到开发人员和运维人员之外,包括测试人员、数据库团队以及将软件投入生产所需的任何其他人。

2014 年 8 月 12 日更新,添加了有关收益和部署给一部分用户的内容。