持续集成之戏说Check-in Dance(2)

　　Joe解释到：“主要是因为我们每个人的本地环境都不完全相同，很可能出现‘它在我的机器没有问题呀’的这个现象，所以还是要在独立的持续集成服务器上再运行一次。”

　　因此，大家就这么决定了。

　　四、两次本地构建的目的

　　四周后的一天，Joe花了很长时间完成了某个新功能后，打算提交了。于是他把分支当前的代码与其本地代码进行了一次合并。然后运行了本地测试，但测试失败了。他用了很长时间来定位该问题是在他自己修改的功能里，还是在被合入的代码中。这让他对提交流程进行了反思。

　　“要是在合入他人代码之前，能够先运行一次本地测试，验证一下我的代码没问题就好了，反正本地测试所花的时间也不长。”

　　于是，他把这个想法告诉了其他人，最后大部分人都同意这么做。于是，其提交流程就变成了这样：?

　　每个人在开发新代码之前，只能从持续集成完全成功的那个最新版本检出代码;

　　开发新功能或修改bug;

　　运行本地测试，如果有失败就立即修复，直至测试成本;

　　提交前将主分支上的代码再次取到本地合并;

　　运行本地测试，确保测试可以通过;

　　提交代码到主分支，由持续集成服务器再次运行测试。

　　如果测试通过，转到步骤(1);

　　如果测试没有通过，转到步骤(2)。

　　这个过程就被称为“Check-in Dance”。

　　Alice还说道：“我们在从主分支上检出代码时，一定是那个通过持续集成验证的最新版本。这样可以避免检出的代码就是有问题的，而影响自己本地的代码。”整个过程如图4所示。

　　五、持续集成令牌

　　过了几天，有人把大家叫到了一起，这次是Alice。她说：

　　“我今天遇到一个问题。我提交代码之后，正等着持续集成服务器返回结果呢，Bob就提交代码了。幸好我提交的代码通过了测试，否则的话，我就要在Bob的代码之上修复啦。所以，我建议我们需要设立一个提交令牌，只有拿到这个提交令牌的人才能提交。也就是说，当一个人做完本地测试之后，去拿这个令牌。拿到之后，再进行代码合并、本地测试和提交。提交以后当持续集成服务器返回成功通过的结果时，才能交还令牌。这样就不会出现我和Bob这种情况了。”

　　可Bob并不同意这样的做法，“这次没有出什么问题，为什么还要这么做呢?”

　　此时，Joe把话接了过来，说道：“Alice的这个建议很好，我已经遇上过一次这样的事情了，那次测试失败以后，我花了很长时间才发现问题并不在我的提交中，而是在Mary的提交中。我把它修复后，又做了一次提交。”由于大多数人都同意这么做，因此团队决定试一试。因为目前测试运行时间很短，所以提交和集成工作没有遇到什么瓶颈。提交流程如图5所示。

　　似乎事情到这里就结束了。然而，这个游戏被某投资公司看中，决定做更大的投入，招更多的开发人员，让它成为一个开放游戏平台。那么，接下来Joe与他的朋友们还会遇到哪些问题呢?

原文转自：http://www.ltesting.net