“看，车来了！不过这趟车貌似咱赶不上了吧？！”
“啊！那快点跑，错过这趟就得再等半个小时！”
……
好无奈，可是真的赶不上也没有办法，这个场景很多人都经历过。
“这个release又是一定包就开始上hotfix，四天跟了四个，我根本没时间做回归测试！” QA小静同学抱怨道。
“每次都是定包后就开始无休止的上hotfix，咱们还不如改成每周发布一次！”Dev大鹏同学也被hotfix折磨苦了。
这是发生在蓝鲸项目的一次真实而平常的对话，跟前面赶公交车的场景有什么关系呢？
发车间隔与发布周期
发车间隔的不同带给乘客的感受会完全不同。
有些公交车很少，每半个小时一趟，有时候眼看着一辆车来了又走了，没赶上的心情无比懊恼，下一趟还得等上半个小时啊！实在着急的可能考虑叫一辆快车赶紧走…
而有些公交车发车间隔非常短，几分钟一趟，就算错过一趟也无需等待太久，只要不是着急去救火的乘客一般都不会太在乎。
项目的不同发布周期带给客户的感受也是类似的。
蓝鲸项目的发布周期跟第一种公交车发车间隔非常类似，是四周发布一次，如果这次没能上线的功能，或者有导致功能不能正常工作的缺陷，下次发布上的话，就得再等一个月。一个月，那是多少白花花的银子啊！对于那些特别重要的功能，客户着急就要求上hotfix，于是就出现了前面小静和大鹏对话中的场景。
Hotfix是否真的能解决软件交付过程中的问题呢？其实不然。
Hotfix的引入带来很多额外的工作，影响新功能的按时交付，会打乱交付节奏，从而有形成恶性循环的趋势。既然这样，大家一定希望能解决，而且通过公交车的例子很容易想到前面大鹏说的那个方案。
如果发布周期缩短，比如说一周甚至更短，这次没上的功能也不用那么着急的通过hotfix来上线，就能解决问题。那么蓝鲸项目为什么不一周发布一次呢？
如何才能缩短发布周期？
1. 合适的迭代计划和合理的需求切分
半个小时一趟的公交车，就算车子足够大能够承载半个小时到达的乘客数，可是会导致乘客等待时间过长，造成很多不便和耽误。要解决这种情况，可以把大型公交车换成多辆小型车，增加发车次数，缩短发车间隔。发车间隔缩短到多少，车子换成多大的都是需要仔细分析和考虑的问题。
映射到蓝鲸项目，要缩短发布周期，就得有相应的小规模需求正好能够乘坐小发布周期那样的小车，要做好发布计划和需求切分。
这样，对需求源的要求很高，需要客户那头的紧密配合。要想缩短发布周期，首先必须得有足够的、粒度合适的功能需求，能够正好安排到较短的发布周期上线。如果需求范围不能提前确定好，就没法提前做好短周期发布计划，不可能把发布周期缩短。
2. 强大的开发能力
乘客的需求分析清楚了，要想缩短发车间隔非常关键的一点就是要有足够的安全的车和靠谱的司机。 如果这一点满足不了，其他都免谈。
对应到蓝鲸项目，安全的车子和靠谱的司机组成了团队强大的开发能力，包括架构支撑和人员技能。
车子就是对持续交付友好的技术架构，需要减少模块间的依赖，比如采用微服务。蓝鲸项目是一个七年之久的老项目，很多陈年依赖已经形成，要拆分不是一时半会的事情，团队正在朝着这个方向努力。
司机就是我们的开发团队，除了要有必要的开发技能外，要做到靠谱就得透彻理解持续交付的精髓，需要团队人人都有质量意识，人人都有发布周期的紧迫感，并且能够做到高效合作，从需求划分、代码质量、测试保障等做好各个环节的工作，做好缺陷的预防和监控，不让严重缺陷流入后面阶段。
蓝鲸项目由于新人较多、人员流动大等原因，对于质量意识和紧迫感都有待提高。 不过，在各位QA的影响下，团队人员的质量意识、紧迫感都在改善，新人的技能也在不断的学习和实践中得到提高，但仍然不能放松警惕，需要时刻保持向前的精神面貌。
3. 充分必要的测试支撑
有了足够的安全的车和靠谱的司机，还得保证路况足够好，这样才能做到不管到达哪个站，间隔都是相同的。
要想蓝鲸项目的持续交付能够顺利前行，一路畅通，需要严格做好质量内建，各层都有充分必要的自动化测试保护，减少新功能开发过程中对老功能的破坏；同时持续集成流水线也要很健全，不能耽误代码提交和出包，从而影响开发和测试的进度。
蓝鲸项目开发年限已久，复杂度很高，在持续交付的路上行走的有些坎坷。目前团队正在这些方面努力采取改进措施，取得了不少进展，但确实还有不少提高的空间。
前景堪忧？
过去七年，蓝鲸的持续交付之路有些坎坷，但不应因此而失去信心。
通过跟公交系统的对比，我们可以看到蓝鲸项目要缩短发布周期、杜绝hotfix，需要从需求切分、迭代规划、技术架构、团队能力和测试策略等多方面进行优化，才能保证持续、快速的发布节奏，这是一个系统的问题。
七年之痒已经平安度过，蓝鲸团队正在采取相应的改进措施，一旦做好了上述各方面的优化，相信下一个七年一周发布一次或者更短发布周期都将不是梦！
