跌撞撞的持续集成之路(2)

　　方案有了，听起来都很有道理，也都有问题。该如何做出决策，是个问题。现在大家众说纷纭，都有理，就变得难以抉择。而且到现在了是不能随便尝试的，这种尝试也是一种风险，一旦出问题造成的成本上升都会加大我们身上的压力。

　　迷茫之下到AgileChina上跟大家讨论了一下。非常高兴的收集到了几方面的建议：

　　Jeff Xiong觉得可以将测试分级，并将build分为两个环节，一个跑基本的用例，一个跑全部的用例。这跟我们的第一套方案的思路吻合。但是这种行为是不是失去了持续集成的意义呢?他也不是很确定，他说：

　　我也不确定……不过，不全面的持续集成至少比不能用的持续集成要好。哪怕一个quick build(只?)能抓到80%(70%?60%?50%?)的defect，如果它只要很少的时间就能跑一遍，似乎值得这样做。

　　不过同时就需要(可能是专门的)人来关注slow build的健康状况，不然broken functional tests可能被忽视并累积。

　　因为是在论坛上，互相之间的交流容易造成理解上的偏差，我便阐述了一下我的理解：

　　嗯。。。也就是说分一个fast build和一个slow build然后有专人关注slow build。

　　那我的理解，这个fast build应该是反映了后台的健康和前台与后台的基本集成的健康。主要用来完成保障集成的角色。

　　而slow build则是反映了从用户接口来看的软件的健康状况，定期回归，防止发生过的错误再次发生。

　　这样逻辑上看着很清晰，但是两者之间的同步。。。会不会有什么问题呢?

　　Jeff Xiong认可了我的理解，并提出了更进一步的解释和建议：

　　slow build实际上是运行完整的回归测试套件。当然理想的情况是slow build基本上不出错，因为*逻辑*用单元测试都覆盖到了，功能测试只是在描述*表现形式*。那么因为slow build基本上不出错，就没有价值每次都去运行它，让它在后台慢慢的跑着，过一段时间(半天或者两小时)去关注它一下，没问题就好，偶尔出了问题就马上解决并且加上对应的单元测试。这样你既节约了时间又不会严重降低对质量的保障力度。

　　实际上的情况可能比较难这样理想，但是和所有好的环境一样，这个环境不是说一下子规划好就万事大吉的。你可能大概的分一分，然后不断的维护，在两组build之间交换测试案例，一些覆盖到大量功能的、经常出错的案例也许要换到fast build的冒烟套件里面，一些看起来永远不会出错的案例也许可以换到slow build去。一直琢磨这个事，它才会变得越来越好。

　　(题外话：最近我觉得稍微大一点的项目应该有比较专注的build master，developers往往并不是特别认真的考虑build和CI的持续改进。)

　　而胡凯则提出了一些基于CC采用分布式的解决思路：

　　CruiseControl是支持一个叫做Distribute的Contrib，它的Idea是：因为CruisControl支持叫做Composite的build方式，那么你可以起多个build server一起来build同一个项目，当且仅当所有的子build通过，整个build才算成功。

　　对于每个build server，你是在单线程测试，对于整个项目，你却是并发测试，因为有多个server同时在跑测试。

　　但是他也说到CC毕竟是开源的东西，配置起来十分麻烦，于是最后也提出了采用Cruise的方案^_^:

　　或者你也可以尝试一下ThoughtWorks新发布的Cruise, 基本的理念很相似， 都是把测试分布到不同的机器上执行。

　　在试用期内可以同时跑6个Agent.你可以在每个Agent上执行不同的Target比如

　　Agent1 : ant ft.suite.1

　　Agent2 : ant ft.suite.2

　　Agent3 : ant ft.suite.3

　　你可以拿来玩儿下，根Open Source的那个比起来，应该容易设置很多。

　　缺点是：

　　你必须使用 hg或者svn 作为 SCM

　　试用期过后，你只有2个免费的Agent

　　另外，糖醋鼻子还提到了分支式开发，大家围绕这个还展开了激烈的讨论，不过我考虑到分支式开发对我们的利可能要远小于弊，最终还是放弃了这个方案。

　　在吸取了两方面的建议之后，经过一番思考，决定开始两方面的准备，一方面，对测试用例的分级方面做了一些工作，重构了一部分用例的结构。另一方面我去调研分布式构建的实现手法。CC的配置果然非常麻烦，调研期间发现了有RemoteAnt这个东西，试了一下基本满足我们的需求，考虑到一个Agent不用做的太过重型，于是就采用了这个方法。在分布式的技术调研已经完成的情况下，测试分级要不要做成了一个问题，但考虑到目前需求只作了1/3，如果这个都抗不住要分级的话，后面的工作就没法做了，所以分级的事情，虽然做了，但是也暂缓实行。

　　现在实践已经采用，会不会产生新的问题呢?前文说过“兴一利必也生一弊”，这个事情是肯定的。那么问题就来了，既然弊端肯定会滋生，我们怎么知道作出的决策是正确的呢?

　　其实，倒回去看这一路走来的过程，除了一个可以运行的过程以外，还有一个很重要的收获，那就是：如何进行决策。而所谓决策，并不是在黑白分明的事情之间做出选择，而是在都有理的事情中做出选择。就像我们都知道做软件设计的时候，设计是没有好坏之分的，只有适不适应你的具体情况之别。所以当我们面临几套解决方案的时候，就好象面对几套设计方案一样，真的是很难选择。如何做?各自就有各自的思路了。像我们就吸收了敏捷开发的思想中所强调得不做过度设计。选择立杆见影的改进去做。同时，像前文所说，抱着拥抱变化的态度，相信兴一利必生一弊并不是坏事。相反，他可以从一定程度上，带领我们找到真正的问题。

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