RSS

Monthly Archives: June 2012

上线,怎么就纠结了?

现象

项目每个迭代结束都发布上线。最近上线模式变了,似乎所有人突然变得很纠结,都围绕着“上线”二字郁闷着:

@ Customer Care Center – 线上版本有个Bug,客户抱怨了,能不能尽快把修改后的功能上线啊。
@ IM – 似乎有些天没上线新功能了,尽快上线一次吧。
@ Business people – 不确定哪些新功能需要在接下来上线啊,反正可以随时上线嘛,让我再想想。
@ UX – 觉得UI还不够好,期望将自己的设计细节被完全实现了再上线,不完美宁愿不上线这个功能。
@ OPS – 一键部署已经完成搭建并随时待命了,终于不用再一个迭代上线一次了。团队可以随时在半小时内将最新代码上线,因此要求主干代码永远干净。
@ TechLead – 要保证主干上的代码随时能上线,同时要保证所有人的代码能持续集成,还要保证没有被Business的人认可的功能暂时不开放,只好选择使用feature toggle的方案了。虽然减少了代码分支的方案可能为DEV带来的集成上的苦恼,但DEVå’ŒQA在新增和测试feature toggle上工作量的增加是逃不掉了。
@ BA – 到底Business的人想要上线哪些功能啊,一会儿要这个一会不要那个?已经打包成了这么多版本的包,每个包里有哪些功能啊,又有哪些是已加上了toggle被隐藏了的啊?
@ QA – 哪能说上线就上线?要保证质量,要按流程在每个环境上测试;不仅测功能本身,还要测feature toggleå¼€/关下的情况,以及层叠的toggle关系下的情况。每拿到一个包,都要把里面开放和关闭的功能历数一遍,好麻烦。
@ DEV – 现在提交代码要小心了,随时上线呢,万一把主干上的代码弄脏了,或者把人家还没决定好要上线的功能忘了加toggle就提交了,那就麻烦了。话说这story不就是改改UI么,偏偏为加个toggle写这么多代码。
@ PM – 协调所有人关于上线的意见真是费精力啊,怎么样才能让事情顺利起来呢?一定有些什么可以做来改变现状的。

梳理

整理了一些因果线索:

1)Business people不确定什么功能需要在接下来上线
=> BA不知道功能的优先级,计划做不好
=> Kick off可能还不能上线的用户故事
=> DEV不得不加toggle以隐藏此功能
=> QA不得不花更多时间去测试toggle本身

2)OPS要求主干代码干净,保证随时能上线
=> 综合Business people对暂时隐藏部分功能的需求,以及代码持续集成的考虑,TechLead敲定使用feature toggle来处理未完成功能和暂不开放功能
=> QA测试工作量增加,同时要求未被sign off的功能必须及时toggle off
=> DEV代码工作量增加,而且在没有加feature toggle或功能未完成前不敢提交代码,代码集成次数减少
=> BA交流工作量增加,不得不每天整理可能上线的版本中所含功能的情况

3)回想从前两周迭代结束时冻结代码并上线的经历:
那时,所有人都清楚代码冻结的时间点,所以只为个别的未完成功能而加feature toggle
<=> 现在,大家对“随时都有可能取主干代码来上线”充满恐惧,因而被迫添加更多的feature toggle或在某些功能完成前不提交。

应对

我逐渐看到了本源,于是有三招出炉。

应对第一招:控制上线时间点,取回部署主动权。

好处是:
* 充分规划在接下来上线的版本中涵盖哪些功能
* 为开发过程拉开缓冲区,减少因未完成功能而加的feature toggle
* 放松DEV们绷着的弦,让他们正常提交,坚持持续集成

应对第二招:功能性问题完成后及时上线,小改进不阻大进度。

想做到频繁部署,一方面要有好的工具能及时部署指定版本,另一方面要对线上版本做好容错准备。一键部署工具确实带来很大的便利,让部署变得快速简单;而always beta的概念告诉我们苛求一时的完美是无意义的,要先容忍一些非核心问题滞留,同时容忍一些状况发生的可能性,或在之后的上线版本中持续改进。

应对第三招:搞清接下来要交付什么,不要盲目开始或盲目等待。

也许你会说,人家Business people没拿定注意要上线什么功能,我能怎么办?当然有我们能做的。
* 给他们压力让他们尽快去想去研究,争取在迭代开始就确定好要上线的是些什么,尽量避免开始一个不确定要不要的功能,以及之后可能出现的需求反覆。
* 保持急需的修改能及时地作为补丁上线。

之后总结

等着看…… 到时再写下来