为什么不能每周发布一次？

文／林冰玉

“看，车来了！不过貌似咱赶不上这趟车了吧？”

“啊！那快点跑，错过这趟就得再等半个小时！”

……

好无奈，可是真的赶不上也没有办法，这个场景很多人都经历过。

“这个release又是一定包就开始上hotfix，四天跟了四个，我根本没时间做回归测试！” QA小静同学抱怨道。

“每次都是定包后就开始无休止的上hotfix，咱们还不如改成每周发布一次！”Dev大鹏同学也被hotfix折磨苦了。

这是发生在蓝鲸项目中一次真实而平常的对话，跟前面赶公交车的场景有什么关系呢？

发车间隔的不同带给乘客的感受会完全不同。

有些公交车很少，每半个小时一趟，有时候眼看着一辆车来了又走了，没赶上会无比懊恼，下一趟还得等上半个小时，实在着急的可能会考虑叫一辆快车赶紧走。

而有些公交车发车间隔非常短，几分钟一趟，就算错过一趟也无需等待太久，只要不是着急去救火，乘客一般不会太在乎。

项目的不同发布周期带给客户的感受也是类似的。

蓝鲸项目的发布周期跟第一种公交车发车间隔非常类似，是四周发布一次。如果功能没能在这次上线，或者有导致功能无法正常工作的缺陷，得再等一个月才能再次上线。一个月，那是多少白花花的银子啊！对于那些特别重要的功能，客户着急就会要求上hotfix，于是就出现了前面小静和大鹏的对话场景。

Hotfix是否真的能解决软件交付过程中的问题呢？其实不然。

Hotfix的引入带来很多额外的工作，影响新功能的按时交付，会打乱交付节奏，有形成恶性循环的趋势。既然这样，大家一定希望能把问题解决，而且通过公交车的例子很容易想到前面大鹏说的那个方案。

如果发布周期缩短，比如说缩短为一周甚至更短，这次没上的功能也不用那么着急的通过hotfix来上线，就能解决问题。那么蓝鲸项目为什么不一周发布一次呢？

半个小时一趟的公交车，就算车子足够大、能够承载半个小时到达的乘客数，也会导致乘客等待时间过长，造成很多不便。要解决这种情况，可以把大型公交车换成多辆小型车，增加发车次数，缩短发车间隔。发车间隔缩短到多少，车子换成多大都是需要仔细分析和考虑的问题。

映射到蓝鲸项目，要缩短发布周期，就得有相应的小规模需求正好能够乘坐小发布周期那样的小车，因此要做好发布计划和需求切分。

这样对需求源的要求很高，需要客户那头的紧密配合。要想缩短发布周期，首先必须得有足够的、粒度合适的功能需求，能够正好安排到较短的发布周期上线。如果需求范围不能提前确定好，就没法提前做好短周期发布计划，不可能把发布周期缩短。

在把乘客的需求分析清楚之后，缩短发车间隔非常关键的一点就是要有足够的安全的车和靠谱的司机。如果这一点满足不了，其他都免谈。

对应到蓝鲸项目，安全的车子和靠谱的司机组成了拥有强大开发能力的团队，包括架构支撑和人员技能。

车子就是对持续交付友好的技术架构，需要减少模块间的依赖，比如采用微服务。蓝鲸项目是一个七年之久的老项目，很多陈年依赖已经形成，要拆分不是一时半会的事情，团队正在朝着这个方向努力。

司机就是我们的开发团队，除了要有必要的开发技能外，要做到靠谱就得透彻理解持续交付的精髓，需要团队中人人都有质量意识，人人都有发布周期的紧迫感，并且能够做到高效合作，从需求划分、代码质量、测试保障等做好各个环节的工作，做好缺陷的预防和监控，不让严重缺陷流入后面阶段。

蓝鲸项目由于新人较多、人员流动大等原因，质量意识和紧迫感都有待提高。不过，在各位QA的影响下，这些问题都在改善，新人的技能也在不断的学习和实践中得到提高，但仍然不能放松警惕，需要时刻保持向前的精神面貌。

有了足够的安全的车和足够靠谱的司机，还得保证路况够好，这样才能做到不管到达哪个站，间隔都是相同的。

要想蓝鲸项目的持续交付能够顺利前行、一路畅通，需要严格做好质量内建工作，各层都有充分必要的自动化测试保护，减少新功能开发过程中对老功能的破坏；同时持续集成流水线也要健全，不能耽误代码提交和出包，以防影响开发和测试的进度。

蓝鲸项目开发年限已久，复杂度很高，在持续交付的路上行走的有些坎坷。目前团队正在这些方面努力采取改进措施，取得了不少进展，但确实还有不少提高的空间。

过去七年，蓝鲸的持续交付之路有些坎坷，但不应因此而失去信心。

通过跟公交系统进行对比，我们可以看到蓝鲸项目要缩短发布周期、杜绝hotfix，需要从需求切分、迭代规划、技术架构、团队能力建设和测试策略调整等多方面进行优化，才能保证持续、快速的发布节奏，这是一个系统的问题。

七年之痒已经平安度过，蓝鲸团队正在采取相应的改进措施，一旦做好了上述各方面的优化，在下一个七年，一周发布一次或者更短的发布周期都将不是梦！