持续集成工具的选择

惩罚是很扯的一件事情。问题关键是工程师们内心是不是关心Build失败这件事情。惩罚也许表面会达到效果，但是如果你作为被惩罚对象或者可能被惩罚的对象， 心里会爽吗？这种管理是没有人性的。所以关键是让工程师真正的接受CI。这需要很多的工作， 例如宣传、知识分享等等。而且要做的好。那种干巴巴的培训效果不大。

cruisecontrol，纵向比，比3年前是好点，不过横向比，还是差……配置烦琐方面我不太确定有没有提升，反正有Hadson和Continuum了，我没有兴趣去尝试一个旧的酸萝卜。

大部分人是知道构建结果就可以了，不过配置管理员还是需要经常访问这个界面的，例如查看更加详细的report，例如测试用例的执行结果历史，测试用例的单元覆盖率，等等…………好的CI，不仅仅是一个配置了，就整天发送邮件的系统而已。

提交前先update的事情是这样的，每个程序员每天把开发密切的项目，更新一次，作为上班前第一件事，是个好习惯，如果做个计划任务，上班到前就执行一次，那就更好。

至于这样做后，一天的开发中，代码冲突的事情，就让scm系统来提示好了，提交代码前先update一次这样的做法，无论如何不是best practice

这种还是要在公司形成一个气氛才行，敬业的气氛，如果有这样的氛围和素质，收到build失败的邮件，那个人都会很不好意思的了，不需要惩罚……

当然，对于不少人来说，还是没这样的习惯，小惩罚……例如，请大家全体吃雪糕之类的，嘻嘻哈哈中而过，我觉得是好团队的习惯，人都是会犯错误的，系统大了，跑全部的测试用例很耗时间的话，难保重构就算过了自己的单元测试，到了CI服务器就能全部通过的，如果说到罚钱扣工资，这个大家都不太舒服，请个小客，我觉得应该也是个Best Pratice。

.....认真了，我输了

.....认真了，我输了

持续集成是最佳实践没错，但也得在完善自动化测试之后才能发挥作用，否则就变成持续编译了。
虽说也有那么点儿作用，但是这种放空枪的事儿很可能会让不熟悉敏捷的团队产生抵触情绪。

同意楼上，团队对CI的需求不可能脱离测试用例而存在。

工具不是一切 持续集成 不是万能

关键在于团队建设管理规范

人才是一切之本，万恶之源

楼上的在说废话