我认为标题总结了这一点。我只是想知道为什么其中一个更适合 Svn 的 Java 项目的持续集成构建。
最佳答案
我同意 this answer ，但想补充几点。
简而言之，Hudson(更新: Jenkins )现在可能是更好的选择。首先是因为通过 Hudson 的 Web UI 创建和配置作业(CC 词汇中的“项目”)比编辑 CruiseControl 的 XML 配置文件(我们过去只保留在版本控制中以便更好地跟踪它)。后者并不是特别困难 - 它只是更慢更乏味。
CruiseControl 非常棒，但正如 Dan Dyer 的博文中所述， Why are you still not using Hudson? ，它首先受到了影响。 (嗯，就像英国，如果你愿意的话，后来进入工业革命，当时其他人开始用更新的技术超越它。)
我们大量使用 CruiseControl，并逐渐切换到 Hudson，最终独占使用它。 甚至更:在这个过程中，我们已经开始将 CI 服务器用于许多其他事情，因为设置和管理 Hudson 作业非常方便。 (我们现在在 Hudson 有大约 40 多个工作:用于稳定和开发分支的常规构建和测试工作；与发布相关的工作(构建安装程序等)；针对代码库运行一些(实验性)指标的工作；运行(慢) 针对特定数据库版本的 UI 或集成测试；等等。)
根据这次经验，我认为即使您有很多构建，包括复杂的构建，Hudson 也是一个相当安全的选择，因为就像 CC 一样，您基本上可以用它来做任何事情 .只需将您的作业配置为按照您希望的顺序运行任何 Ant 或 Maven 目标、Unix shell 脚本或 Windows .bat 脚本。
至于第 3 方的东西 (mentioned here by Jeffrey Fredrick) - 这是一个很好的观点，但我的印象是 Hudson 正在迅速追赶，并且已经有大量的 plugins available为它。
对我来说，我想念 CruiseControl 的两件事是:
- 其关于构建损坏的警告电子邮件比 Hudson 的警告电子邮件更能提供信息。在大多数情况下，根本原因从 CC 格式精美的 HTML 邮件本身就很明显，而对于 Hudson，我通常需要点击 Hudson Web UI 的链接，然后单击一下以获取详细信息。
- CruiseControl dashboard开箱即用，更适合作为“information radiator”(显示在公共(public)监视器上，或投影在墙上，以便您始终可以快速查看所有项目的状态)。在 Hudson 的首页中，我们需要一些 Greasemonkey 技巧来获得漂亮的绿色/红色作业行。
次要免责声明:我在过去一年左右没有密切关注 CC 项目。 (但从 quick look 开始，它并没有发生任何戏剧性的变化。)
注意 (2011-02-03):Hudson 一直是 renamed/forked如Jenkins (由 Hudson 创建者 Kohsuke Kawaguchi 和其他人提供)。看起来甲骨文(控制着 Hudson 名称)也会保留“Hudson”，但我个人的建议是使用 Jenkins，不管甲骨文怎么说。
关于java - 用于 Java 项目的 Hudson 和 CruiseControl 有什么区别？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/604385/