持续集成工具的选择

嘿嘿，你还是对基层程序员的水平太乐观了～～
我最近在客户这遇到的情况：项目组里有个CruiseControl在跑，但是找几个程序员一问，都不知道地址在哪里，从来不看的。于是找台电脑打开，问，大家都知道这是什么吗？然后看见一片茫然的表情…第二天突然发现CruiseControl被关掉了，一问咋回事，有人说，哦，那玩意老是发邮件（build失败），烦人得很。

很多你认为理所应当的事，其实很多人不这么认为，这种事情，一定要有所觉悟才行亚～～

嗯，请访问你的cruisecontrol的 /dashboard

鸟的...outlook
配的乱七八糟
都是为了自动邮件.....

太多的无聊邮件了....
基本找不到有必要看的东西了...

有些人在BTS上聊天....讨论....想杀人


楼上有没有些可用的秘笈?
分享一下?


如果你不认为布署工程师也算是人的话.....最后一天给代码让他去布也是可以的.

顶楼上的
我们的CI现在主要职责是：
1. 从早期开始持续维护项目部署
2. 快速给客户/老板/自己查看项目效果与进度，让大家感受到项目健康状况和成就感
3. 为懒到不想在自己机器上起应用或是嫌自己机器内存不够的开发人员提供测试环境

我们实施的是Hudson，简单方便

ps. 我没觉得Hudson的分布式构建如楼主所说有啥不方便的

恩恩，跟俺们这差不多

1.有CI工具的话当完成一个功能的代码提交后测试可以及时取得版本测。
2.及时编译能及时反馈项目的可运行情况，健康度。
3.加上自动化单元测试，回归测试能保证项目再被改动重构后，项目正确性，完整性，可靠性能得到及时验证。

您做过开发么？
难道是我孤陋寡闻？"提交前先update" 这种事务性操作，据我所知计算机还不会做，你打算让计算机去提交什么？
"谁出错谁恢复"  这个"谁"只要看一眼svn日志就可以找到。

非常感谢楼主提到我们开发的QuickBuild。现在的很多持续集成工具可以做到提交之前先update，流程是这样的：
1. 开发人员向持续集成工具提交一个proof build。
2. 持续集成工具负责update你的工作拷贝（通过IDE的plugin，或者是开发人员机器上安装的agent）
3. 持续集成工具收集当前要checkin的内容发送到服务器与最新的代码集成，并运行测试用例。
4. 如果集成成功，你的代码将会被自动checkin。

这样的好处是只要大家遵守这个约定，基本上可以防止明显有错误的代码checkin到版本控制系统中。

万一有错误代码checkin导致集成不成功，持续集成工具也可以自动运行iterative build，也就是一个revision一个revision的去运行build，直到找到“干坏事”的人，并通知他去改正。

对持续集成本身不感冒的团队，也可以利用持续集成工具做开发流程的更好整合。在软件开发中，build是一个比较核心的东西：开发团队的目的是向测试团队提交一个可供测试的QA build，而测试团队测试该build，并确认它是否达到要求的质量标准。测试通过的build会被提交给发布经理进行发布。最终客户拿到的就是一个release build。Issue实质上也都是针对特定的build而言，绑定到build上面的。持续集成工具可以让这个过程自动化起来：
1. 一个阶段的开发结束后，开发组长把开发人员粗略测试过的DEV build，提升为QA build。在提升的过程中，持续集成工具可以到issue track工具里去收集跟这个build相关联的issue，对版本控制系统打上合适的标签，并且把它自动deploy到测试机器上等待测试。
2. 持续集成工具告知测试组有一个新的QA build等待测试，并且显示相关联的等待验证的issue。测试组运行相关测试用例，通过后把这个QA build标记为golden build，并通知发布经理。
3. 发布经理把golden build提升为release build。在此过程中，持续集成工具可以去自动给版本控制系统打上release标签，更新公司网站显示最新版本的下载，并且通知客户有新版本fix了他们关心的bug等等。

在我们自己的实践中，每次发布版本之前，我们先通过http://build.pmease.com构建一个QA build，并自动deploy到测试网站(http://demo.pmease.com)运行测试用例，自动化测试通过后，我们做些手工测试，满意了就把这个QA build提升为release build，网站的下载链接（http://www.pmease.com/downloads）自动得到更新，客户也自动得到通知。

致敬！想不到你是中国的？我发了MSN给你，有空请你到我们公司来聊聊吧。目前我们已经购买了你们的Service，非常喜欢你们写的这个系统！也祝你们好运！


非常赞同！我们正在尝试这个proof build，但是好像现在缺少IDE支持，显得还不是很方便，不知道是不是这样？以后你们会有IDE的集成吧？

看了很多回帖讨论有关持续集成是否必要，我有点无语，持续集成作为best practice已经是毋庸置疑，就像SCM工具，Bug Tracking工具，现在应该是每个开发团队所必备的吧。如果说有人和你讨论你公司用没用Bug Tracking，用没用SCM，你是不是会觉得有点搞笑？诚然，如果没用Daily Build，我们可以工作的很欢乐（因为我们不会收到那些所谓的垃圾邮件）。其实，如果没有Bug Tracking，我们会工作的更欢乐，因为，我们不再为考核我们的efforts而烦恼，也不会被该死的经理追在屁股后面骂：XXX，快点回公司，你还有N多bug没有fix！

我们在实践中，持续集成和冒烟测试相结合，有专门的自动化测试环境用于验证每日构建的最新版本是否可以通过所有的自动化测试用例。
我们鼓励更早的checkin代码，这样便于最快的发现问题。
这样也节省了开发人员搭建环境来验证代码改动是否影响其他功能。
现实中，验证bug是否修改最难的一点是很难确定是否对其他功能造成影响，而冒烟测试可以改善这点。
持续构建和冒烟测试越早使用，产生的效益越大。
自动化测试用例数目越多，产生的效益越大。