共计 2358 个字符，预计需要花费 6 分钟才能阅读完成。
当今软件开发领域的一个有趣特征是，尽管有些人认为“持续交付”已成定局，但仍有许多团队没有看到或正在努力实现收益。release 少量功能的想法通常看起来像是一种简单的解决方案，可以减轻因大量风险性发布而带来的痛苦，我们以此方式解决了非常困难的障碍。
今最流行的软件开发方法是 Scrum。Scrum 提倡让您的应用程序准备在每次（大约两周长）冲刺结束时发布。我不是在这里挑刺 Scrum 团队，但是将多个功能捆绑到发行版中然后再部署到生产环境中的任何方法都是有问题的。
- 他们将许多功能和修补程序捆绑在一起。如果其中任何一个在测试中失败，它将延迟整个捆绑包。如果其中任何一个生产中断，则需要回滚全部功能。
- 仅仅因为还有更多的东西，它们增加了某些东西中断，测试失败等的风险。将大量 release 视为大量小风险粘合在一起，形成巨大的风险球，然后将其扔到生产环境中。
- 增加了工作量 - 似乎已经完成（编码）但实际上正在等待下一步（测试，生产部署）的工作，这可能会将其发送回 pipeline 中的上一个阶段。
鉴于大量发布会带来风险并且容易出错，为什么这么多团队仍然坚持使用它们呢？我发现有两个重复的问题不利于采用“持续交付”：打破旧习惯和错误的期望。
CD 如何打破旧习惯？
CD 在发布过程中转移了隐藏的瓶颈。对于开发人员而言，带着一种祝福的心态移交给 QA 和运维，延迟了在真实环境中发生不可避免的混乱，感觉上像在提高生产力。从团队经理的角度来看，它看起来也很有成效。在大多数 sprint 中，开发人员似乎忙于编写代码。发布日期临近时会发生什么？在进行所有测试并可以关闭办公室的灯之前，需要付出巨大的努力进行测试，发布，修复构建并再次进行测试。
许多管理人员和开发人员都接受了看似高生产率和易于出错的版本之间的这种迭代，这是软件开发的事实。从这个角度来看，“持续交付”看起来是违反直觉的：如果发布是压力大，容易出错的事件，为什么会有更多的发布？
错误的期望
采用 CD 的第二个障碍是抱有错误的期望。我们每个人都在观看讨论并阅读有关将 CD 部署到每天生产 50 倍的公司的博客。对不对？但是我们并不觉得这对我们很重要 - 我们的客户可以每隔一段时间看到一个新版本就完全可以了（也许更加舒适）。因此，CD 并不适合我们，它适合那些出于某种原因始终必须交付新产品的其他公司。
这些成功案例中通常会丢失的是，这与客户无关。这是关于公司内部软件开发的方式。关于小幅提高生产率和管理风险。即使许多敏捷团队设法忽略它，这也是一个非常敏捷的想法。
限制正在进行工作的重要性
那么，与发布大版本相比，交付小版本如何提高生产率？关键是正在进行的工作。进行中的每一项工作都会减慢团队的速度，并且某个功能只有在投入生产后才能准备就绪。应用程序或基础架构中的任何更改都需要经历几个阶段。最后一个阶段是以某种形式将更改登陆到用户计算机上。一旦应用程序实现了对用户的用途，并且所做的任何更改都没有使该项目失效，则可以选中该项目，并且不再构成任何风险。
非所有环境都允许将每个功能始终独立地推送给用户。公共 Web 应用程序是最好的，而第三方交付的企业应用程序通常是最差的。如果您的环境不允许每天向最终用户推销，请尝试使其尽可能接近他们。抓住一些业务分析师并将其视为真实用户（迁移数据，仅通过官方渠道进行交流等）。
尚未进入用户手中的每个功能都想像成准备就绪的炸弹。进行中的工作既分散精力又是风险。
让我们来说明一下进行中的工作会如何吸引您。您的 CatsRUs™团队正在忙于完成冲刺，而企业急于提供新的排名按钮，该按钮可使用户给猫照片 1 至 5 星。您有一个由 8 个开发人员，4 个 SET（测试中的软件工程师）和 2 个 SRE（站点可靠性工程师）组成的庞大团队。
由于 sprint 持续了两个星期，因此您希望在发行版中获得尽可能多的功能。8 个开发人员可以轻松地开始处理 6 个不同问题的 sprint，甚至可能在两周内完成 10 个。其中之一将是销售部门脑门热的时候签署合同所承诺的排名按钮。
排名按钮上的工作进展顺利，三天后已通过质量检查。团队感到放心，将精力集中在完成其余功能上。用户管理的改进将需要更改数据库架构，但是应该可以很好地进行处理。最终，在第二周结束时，所有功能要么完成，要么从冲刺中删除。团队已准备好将所有内容打包并发布。SRE 部署到登台环境，并注意到该应用程序无法正常运行 - 用户无法登录。事实证明，另一个功能是在发行前的最后一天完成的，尚未通过新的用户数据库模式进行测试。
因此，该版本需要回滚以解决该问题。修复和回归测试将花费 2 天的时间来测试所有可能受影响的内容。管理层很紧张，团队没有休息，但是终于有一个新版本发布并成功部署到生产中。一项不重要的更改意外地延迟了一项重要功能的交付。
生产中的某个功能出了问题，因此该版本会回滚。
解决上述问题的绝佳方法是持续交付。将该排名功能一直推到生产阶段，而不会与其他任何功能捆绑在一起。它可能不如在晴天无事的情况下创建大型发行版那样有效，因为回归测试和部署需要做更多次。但是，降低风险和加强控制可以弥补这一不足。当然，如果您投入精力，回归测试和部署都可以越来越自动化。
在连续交付过程中，存在问题的功能不会回滚其他功能。
结论
在采用敏捷的工作方法之后，持续交付是您可以对交付过程做出的最重要的改进。通过批处理较大版本的功能来进行工作将最终增加部署风险并降低团队生产力。试用 CD 几周，您会发现交付过程甚至变得更加简单，因为许多项目管理都围绕着跟踪正在进行的工作项。
对于真正高效的 CD 过程，流水线各个阶段的自动化至关重要。灵活的应用程序体系结构，例如围绕独立微服务组织的体系结构，还有助于安全地部署各个变更。这些问题不在本博客的讨论范围之内，但是一旦您采用持续交付，就需要注意在这些方面对团队造成更大的压力。
