持续集成之“测试三角形与分段构建策略原则”(2)

　　“不对，这里有问题!持续集成强调尽早反馈。如果把测试分成两个阶段了，那反馈周期不是加长了 吗?”Bob反驳道。

　　Joe 点点头，说道：“你说的没有错。但是，根据我们现有的软硬件资源条件，我们目前还无法通过增加资源的方式来缩短所有测试运行的时间。所以我们必须在质量与速度之前做出平衡。这也是我为什么要把那些不易出错的自动化测试集合放在第二阶段构建的原因，这样可以降低但不能完全解除第二阶段构建失败的风险。所以， 这也要求我们大家当第二阶段构建失败时，也要找人尽快把它解决，并且把相关的测试再次放回提交测试阶段中运行，或者在提交测试阶段加入新的测试来补充。”

　　Alice此时插话，问道：“既然第二阶段构建不常失败，为什么我们不定时运行它，比如每天晚上运行一次呢?这样不是更节省资源吗?另外，如果第二阶段构建运行得慢，那它不是一直都落后吗?”

　　“因为每次提交阶段构建成功以后就触发第二阶段构建，这样无论如何都比每天晚上运行一次的更多的反馈。因为每天晚上运行一次的话，如果出了问题，我们只能在第二天早上才能发现。对于你的第二个问题，我画一张图来解释。”Joe找了一张大白纸，在上面开始画了起来。

　　一会儿功夫，几个示意图就画好了。看到这几个示意图以后，大家恍然大悟。如图5所示。从图中我们可以看到：

　　当版本123的第二阶段构建被触发并正在运行，Alice又提交了一次，触发了版本124的提交构建;

　　当版本124的提交构建完成之后，由于版本123的第二阶段构建仍在运行，所以不再触发第二阶段构建;

　　当版本125的提交构建完成时，版本123的第二阶段构建仍旧在运行，所以也不触发第二阶段构建;

　　当版本126提交构建正在运行时，版本123的第二阶段构建刚完成，此时由于版本125的提交阶段构建是一个最近 成功完成的提交构建，所以持续集成服务器就会启动该版本的第二阶段构建，而忽略版本124的提交构建。

　　“那根据我们持续集成纪律，谁的提交让构建失败，就由谁来修复。如果版本125的第二阶段构建失败了，就包括版本124和125两次提交的变更，由谁来修复呢?”Bob接着问道。

　　“这个好办，由这两个提交人一起负责修复。如果想确切找到谁的提交有问题，还可以手动触发版本124的第二次构建。假如构建成功，说明版本125有问题，假如构建失败，说明问题在版本124就引入了。”Alice抢着说道。

　　讨论到这里，团队成员都达成了共识：(1) 开始加强单元测试的力度;(2) 在反馈速度和反馈质量之间做出折衷，使用二级构建构建的方式。

　　整个产品的开发非常顺利，马上就要进行版本发布了。团队还会遇到什么问题呢?他们是如何解决的呢?请听下回分解。

原文转自：http://kb.cnblogs.com/page/91338/