持续集成，to be or not to be

这个你可以下载我的试试,包含完整的编译,单元测试及相关打包.

http://code.google.com/p/rapid-framework/wiki/cruisecontrol

文还不错。但总感觉是“市场行为”，尤其看到首页上的广告。

 

 

我不明白为什么要很多人一起在下班前提交, 这样如果一个人的修改有问题会导致整个build失败, 没有办法验证其他人的修改. 有什么其他的原因吗?

 

我们目前是每对pair完成一个功能后都提交,通过build grid很快知道结果, 每个人都必须保证单元测试通过, 如果失败了就得马上修改, 集成测试可以第二天修改(如果已经下班了), 好处是: 

1. 充分利用 build grid, 测试时间也很短

2. 每次build只有少数人, 有了问题容易发现

3. 如果build失败, 或者有人马上修复, 或者rollback上次修改, build成功前其他人不能提交新东西, 不然不知道谁break build.

 

   我们公司就用上了持续集成，每相隔段时间，就build一次，自动归版本，自动部署，自动测试功能(自动测试用例还在完善),感觉挺好的。不清楚gigix认为"头破血流"以及"幼稚"是指什么?
   不过我认为，持续集成在规模大,周期长的项目中，有突出的体现. 如果比较小，周期短的项目，可以裁减部分流程。
以项目大小，取决于流程的优化，也不用太强求走到每个流程

Ant脚本很简单，基本上就是如下几个target
prepare, compile, checkstyle, findbugs, pmd, emma.instrument, junit, emma, all
具体过程就要看你自己的项目情况了。

配置文件？QuickBuild好像没有什么地方需要写配置文件的啊。如果是怎么设置你的configuration的话，可以看文档或者demo.pmease.com，我主要是参考wiki和这个站点来配置的。

持续集成本身的成本我想也许就在于配置和学习持续集成工具本身吧，还有就是购买的成本了。别的，我还真不觉得有什么其它的成本。至于不适用的场合，可能一个人的项目就不需要吧，还有就是特别小的项目不需要吧。我还真的想不出甚么情况来:)

 

下班前要check in只是一个约定，而不是集中在下班前做check in（有点绕，呵呵）。无论build是否会失败，没有关系，我们第二天都可以知道具体情况的，也便于第二天的code review。至于不能验证其他人的修改，对我们而言，不算特别重要，因为不是明天就要发布，昨天没有成功，今天可以继续运行嘛。导致build失败的人，在做code review的时候就可以知道是谁了，他可以在修正了错误之后，做一次手工的build来验证一下，也可以留到晚上自动做。我们只要求不要有连续几天的build失败即可。如果出现这种连续几天的失败，小组成员就会一起停下来协助出错成员修正错误直到build通过为止。

 

至于，你提到的方式的确是现在正在流行的一种方式，也很敏捷，就是利用proof build来做，在submit到SCM之前，由QuickBuild自动触发一个build，如果通过就check in，否则就不做check in。这种方式现在我们只是试验性的使用了一下，还没有感受到什么特别的好处。

这个恐怕要看你怎么使用configuration了，如果你一个项目对应于一个configuration的话，那么你可以管理16个项目吧。如果你像我文章里的配法，可能只够管理3～4个项目。一个项目对应于4个configuration，当然你也可以裁减这种配置来对应你自己的流程。

1.不建议下班前check in,因为如果提交了编译不过的代码第2天来到一看全是红灯就傻眼了。呵呵。

1.持续集成是迭代的方法保证程序质量的方式，无论大小项目都适合。
2.如果觉得产品质量和代码质量很重要，那么持续集成是首选，如果不是，可以跳过。