14.每日构建

其实晓川也没有完全的把握。但是事实证明了每周一轮集成是可行的。不仅可行，而且集成比以前更顺利。第一次未隔周就进行的集成，没把握，晚上加了加班，第二天中午竟然就做完了。随后一周的集成也是这样。

晓川开始主动提出更密集的集成：“老大，其实每天集成，也差不多能行。只要晚上稍微加一点班。”

老大说：“好。要是能不加班，就更好了。”

晓川：“嗯，三点开始集成，到六点下班。如果比较顺利，基本没有版本合并冲突，也没有什么构建错误，那倒是够。但这很难保证。”

老大：“最好是偶尔才需要加班。对了，我记得以前是下午一点开始集成。现在改成下午三点了。如果改回去，是不是加班就能少一点？”

晓川：“那倒是。不过……”

老大：“这只是我的建议。你去和项目上讨论吧。”

晓川去和老刘讨论每天出一个基线。老刘说，他举双手支持。晓川再提把提交截止时间提前的事儿。老刘沉思了一下，露出狡黠的笑容，“其实把提交截止时间定在啥时候都无所谓。不过既然你想提前，那我就帮你提前。”

在项目例会上，大家觉得每天集成这个提议不错。但是有些同志对集成时间提前到下午一点钟表示担心。于是老刘说：“过去我们特别在意集成的开始时间，因为错过了这一次，就要再等一个星期。以后就没必要啦，反正一天一集成，今天没赶上，还有明天呐。”

有个开发组长不同意：“现在提交得先升级任务分支再构建。就一上午的时间，中间在再出点儿错，怕就来不及了。拖到明天，明天再出错怎么办？”

晓川解释说：“要是集成下午一点钟开始，从经验上看，当天下班前大概就能做完了。这时候有提交的程序员就可以升级任务分支，然后启动编译构建，等第二天早上再收结果。这样就把晚上的时间利用上了，还不用加班。”

开发组长：“现在构建分编译和链接两步，然后还要加资源文件进去。所以启动构建后，还得人盯着，程序员得加班才行。”

晓川：“我写了个小脚本，可以把它们串起来了。我自己就在用。”晓川现在集成的任务量不大了，所以有空的时候，在学习脚本语言。这是他的一个小小的成果。

开发组长仍然坚持：“如果你下班前没完成集成呢？那程序员得加班等着你出基线？”

老刘发话了：“晓川，这种情况的话，就不必要求必须基于最新基线了吧？前一天的基线，也差不多吧？”

最后讨论的结果是，大家同意了每天下午1点钟开始集成。前提是，如果下午5点半之前，当天集成结束，那么第二天的提交必须基于这个基线。而如果当天集成没有在下午5点半之前结束，那么第二天的提交可以基于上一个基线。