您使用哪个持续集成框架，为什么？[关闭]

有很多不同的持续集成（CI）框架，我想知道哪种框架最受欢迎。您在您所在的公司使用了哪些框架？

是否有任何理由使一个CI框架比其他CI框架更受欢迎-也许与它提供的功能，集成到其中的东西有关？

似乎在Java和.net世界中使用持续集成比使用ruby或python要多。为什么是这样？

哈德逊或詹金斯（后者是前者的分支）。原因：它很简单（安装和使用简单）并且具有很大的灵活性。这些插件增加了我能想到的几乎所有功能。

几年前，我使用了DamageControl。它也很容易使用，但没有插件。但是作者决定放弃这种简单的解决方案，并开始开发一个新版本，该新版本由不同的服务器相互通信组成（到底是什么？）。效果不佳，该项目被放弃了。我一直在搜寻中，但是Cruisecontrol（过于复杂）或continuum都没有真正找到我。直到哈德逊（Hudson），从一开始我就开始工作。

我在工作和在家中都使用TeamCity。它对各种构建工具都具有强大的支持，并且可以通过插件进行扩展。

在我的书中，无需处理大量用于配置的XML是一个很大的优点，免费版本足以满足我的家庭需求。

我在TeamCity中遇到的一个问题与试图使其自动对.NET程序集进行版本化有关。我必须设置一个相对复杂的解决方法，但是一旦安装妥当，它就像是一种魅力。

就个人而言，我只使用过CruiseControl和CruiseControl.Net。其原因与经济学有关。它们相当稳定，一旦您设置好它们，几乎不需要做任何维护。用户社区通常非常有帮助，并且可以扩展到您的需求。

就是说，据我所知，有几种商业产品（一种是由JetBrains提供，另一种是Atlassian提供），它们提供了更好的设置经验和商业支持。我一直想尝试这些产品，但实际上还没有机会。

与解释型语言相比，CI工具在编译语言中的作用更为重要，但这并不是说CI工具浪费在解释型语言上。当您有多个相互依赖的项目，并且想要确保所做的更改不会意外破坏其依赖关系时，CI工具是无价的。

CI工具可以帮助您解决三种常见的问题：

1. 编译错误-如果类的签名以打破依赖关系的方式发生更改，则最好在放弃可交付成果的时间之前了解它。
2. 逻辑错误-如果类的行为以打破依赖关系的方式发生变化，则最好尽早了解它。这必须通过某种自动化测试来检查，最常见的是单元测试。
3. 验收测试-如果您要在成品上运行一套自动化测试，则最好经常运行它们。

解释的语言不会编译，因此不会出现编译错误。但是，另外两个问题很常见，以至于CI工具可用于Ruby / Python / Perl / etc中的项目。

逻辑错误和验收测试点中的关键词都是“自动化”测试。如果您没有一台可以运行的测试套件，那么您确实会错过CI工具的更多好处。自动化套件可以随着时间而建立，因此您可以从小处着手。

编辑

有关大量CI工具（其中许多我不了解）的功能比较，请参见以下图表：

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix

Team Foundation服务器

Solid CI，与Visual Studio的紧密集成以及作为版本控件的Git。我见过像Hudson这样的更灵活的CI服务器，但是TFS与其他产品的紧密集成使体验如此无缝，以至于对我的团队来说是有意义的。

我都用 CruiseControl.NET和Hudson。我的一些构建在其中一个之上，而另一些则在另一个之上。

为什么？ 因为我不是建筑工程师，而作为建筑工程师的他是这样设置的！

我的构建方式或任何一种产品的投诉都没有问题。我实际上是在向您报告事情的真相，并希望您对此观点表示赞赏！

更新：自从我发布答案以来，哈德森就已经分叉并成为詹金斯。以上建议适用于詹金斯。

脉搏。它基本上就是Just Works，对于繁忙的建筑工程师来说，这是很大的事情。他们也有非常出色的技术支持。我之所以如此喜欢它的主要原因是，我们有250多个项目，并且可以毫不费力地处理它们。我不能对哈德森说同样的话。

我们的团队主要使用Python，C ++和Java。我们将Buildbot用于CI。我们最初开始使用它是因为它与Trac集成在一起，并且因为它看起来很简单明了。我相信它是Python世界中首选的CI框架。

哈德森。有时这有点麻烦，而且某些更有趣的插件实际上并不起作用，但是只需一点点手持就可以使用。

我可能会改用Pulse，但是如果您需要在多个平台上构建，则需要> $ 5k，这有点多。

CruiseControl.NET用于持续集成。尽管我们在CruiseControl中设置了大量构建项目，但CCTray桌面任务栏应用程序的响应速度非常好，即使刷新间隔很长，CCTray桌面任务栏应用程序也无响应。

NAnt用于在CruiseControl项目中执行的构建脚本。对于更复杂的构建脚本，我们用自定义C＃NAnt任务扩展了NAnt，这非常好-用C＃编写代码比创建NAnt脚本更有趣。

我们是一家Microsoft商店，理论上，一旦我们将Team Foundation Server环境迁移到2010年，它将迁移到Microsoft的Team Build 2010。

请注意，无论是否运行CI引擎，都应该能够从命令行构建应用程序。

这意味着CI引擎所做的只是将您的构建调用系统化，并且您可以选择最适合您的特定需求的引擎。

就个人而言，我之所以喜欢哈德森，主要是因为它“感觉”不错，但是我知道，如果一切都失败了，我可以不费吹灰之力就切换到另一个。如果是这样，我可能会首先研究Atlassian开发的程序，因为我喜欢他们制作的其他程序的“感觉”。

请注意，可互换性意味着它们使用什么语言都无关紧要。我相信Java被选择用于许多引擎是因为支持的许多平台以及易于使用的许多构建块。需要一台Web服务器-抢一台。需要许多并发线程-只需使用它们。需要可扩展性-放入罐子中。

在我听说“连续集成”一词之前（这是在2002年或2003年），我写了一个每晚连接到cvs的构建脚本，获取主项目和五个较小子项目的完整副本，构建了所有然后通过ant罐子，然后通过第二个使用tomcat ant任务的ant脚本构建并重新部署WAR文件。

它在晚上7点通过cron运行，并发送了带有一堆附加输出文件的电子邮件。我们在整个项目的7个月中一直使用它，并且在接下来的20个月的维护和改进中一直使用它。

它运行良好，但是仍然比ash脚本，cron和ant更喜欢hudson。