经过持续交付提升生产率

当今软件开发领域的一个有趣特征是，尽管有些人认为“持续交付”已成定局，但仍有许多团队没有看到或正在努力实现收益。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过程，流水线各个阶段的自动化相当重要。灵活的应用程序体系结构，例如围绕独立微服务组织的体系结构，还有助于安全地部署各个变动。这些问题不在本博客的讨论范围以内，可是一旦您采用持续交付，就须要注意在这些方面对团队形成更大的压力。