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没拿定注意要上线什么功能，我能怎么办？当然有我们能做的。
* 给他们压力让他们尽快去想去研究，争取在迭代开始就确定好要上线的是些什么，尽量避免开始一个不确定要不要的功能，以及之后可能出现的需求反覆。
* 保持急需的修改能及时地作为补丁上线。

之后总结

等着看…… 到时再写下来