CI服务器的比较？
我正在寻找不同的持续集成 （CI）服务器（特别是.NET）的比较，并找不到任何。
因此，我想知道您对可用的不同解决scheme有什么看法，有哪些优缺点，托pipe要求是什么以及为什么CI Server XY是您所select的服务器。
我对你的想法感兴趣（随时对其他人发表评论）：
- 哈德森
- 巡航控制
- CruiseControl.NET
- TeamCity的
- CIFactory（使用CruiseControl.NET）
兴趣点是：
- configuration（简单，灵活）
- 与SCM集成（特别是像git或hg的DSVC）
- 与构build系统集成（MSBuild，NAnt，Rake）
- 与testing框架集成
- 与Source Anaylsis集成（Simian，NDepend，FxCop，NCover等）
- WebInterface /仪表板
- 基础设施要求
如果没有链接到大型CIfunctionmatrix（Web Archive）的链接，就不会有这样的问题，它列出了几乎所有的CI选项。
但是，我认为重要的是outlook你希望包含在你的CI系统中的范围。 是要build立还是要引入静态分析，跨项目依赖项，部署，functiontesting等其他元素。为了帮助完成这个规划，我创build了这个关于企业CI元素的挂图（PDF ;不需要注册）。 请不要让这个“E字”把你放下; 我的意思是超越基本快速反馈CI构build的东西。 🙂
它不是特定于工具的，但列出了您在计划/评估阶段时可能考虑的各种实践。
没有什么帮助：
- 比CruiseControl for .NET CI更好的吗？
- 持续集成服务器
- Hudson或Teamcity持续集成？
- 您对CI服务器git支持（Windows）有什么经验？
- 语言不可知的自动化构build和testing服务器，用于多个项目
- 根据我的需要select正确的CI服务器。
- Cruise与TeamCity对比CruiseControl.NET
- CruiseControl [.NET]与TeamCity的持续集成？
- 等等等等
编辑 ：由Jonik在评论中指出，我错过了Hudson和CruiseControl的Java项目之间的区别是什么？ 以及如何以及为什么build立一个C＃构build机器？ 。 你会发现非常有见地的答案。 换句话说，我认为你正在寻找的东西已经在Stack Overflow上了。
TeamCity有一个很好的function，允许开发人员在提交之前执行个人构build。 很有用！
CruiseControl.NET是一群中的老大，因此有点过时了视觉等等。因为它已经有一段时间了，谷歌知道如何解决你会遇到的许多问题。
由于这些原因（其中包括），我使用CruiseControl.NET在工作和TeamCity在家里，在我的开源生活:)
我是一个CruiseControl.NET用户。 我的团队在工作中使用它，并将其用于个人项目。
特别是，CruiseControl.NET允许我运行整个CI过程：构build，版本更新，单元和集成testing，源代码或候选版本的存档，代码覆盖率，甚至部署到我们的工作testing系统。 它是高度可定制的，适用于MSBuild和NAnt，甚至有一个可扩展的插件体系结构。
它几乎做我需要的一切。
最大的缺点：configuration有时是一种痛苦，可能需要时间。 但一旦完成，就完成了，正如另一张海报所说，我喜欢看到“成功构build”的信号，因为我知道构build本身不仅工作，而且我的单元和集成testing都成功运行。
团队基础构build是一个选项，它与Team Foundation Server的交互也非常好。 只要您获得TFS授权，它就是免费的。
我们在工作中使用哈德森。 主要的原因是，它很容易设置。 你可以直接执行战争（这是一个可执行的jar），或者在任何servlet容器上部署它。 你准备好开始了。 而且Hudson支持很多工具，通过它的插件系统可以扩展。
我们从CruiseControl.NET切换到TeamCity主要是因为configuration简单。 TeamCity也有更多的function，但主要原因是一个漂亮的Web UI比XMLconfiguration文件更易于使用。
编辑：TeamCity将开箱即用的大多数任务; 必要时我们使用NAnt。
CruiseControl.NET – build立起来可能有点痛苦（就像大多数CI系统一样），但值得一提的是。 我目前已经设置好在完成构build之后运行unit testing，并按需生成Wix安装程序。 丹说，它看起来有点过时，但这并不重要，因为它提供了大量易于阅读和易于阅读的信息。
一件事 – 确保你所有的开发者安装了CC Tray，运行并指向他们的构build。 在通知栏中获得“另一个成功的构build”是一种非常棒的感觉。
我们在工作中使用ccnet，对于我们的大部分需求（我们有大约50个自动构build版本）都很好，但是需要一个人进行全面的调整和修复。
如果你从头开始，请看看竹子。 我们已经研究过它，看起来确实很有希望，但是这并不能完全符合我们的需求，现在我们已经花费了太多时间在ccnet上转换到Bamboo了。
问候，
Sebastiaan
我inheritance了一个luntbuild服务器。 不是一个.NET项目的好select。 如果你发现你经常回头使用构build服务器来运行通用的命令行任务，那么有些地方是错误的。 一个好的构build服务器很好地理解了unit testing输出和msbuild任务，而不是在源代码控制系统改变时运行的不透明命令。
我正在享受迁移到Team City的乐趣。
我对CI场景相当陌生，我一直把精力集中在CruiseControl.NET上，使用NAnt和Ivy构build我的.NET项目。
我发现CruiseControl.NET对很多其他工具非常适用，例如NCover / NUnit /等。 他们都插入到这一点，并将结果集成到一个组合的构build过程中。
为了我自己的利益，我会在不久的将来考察TeamCity，但是我认为CruiseControl做得很好，但是和build脚本一样好！ 如果这些裤子，那么你的构build只能预期是好的。
但总而言之，CruiseControl.NET是一个很好的解决scheme，但我还没有find比较好的竞争对手。
我们对哈德森感到满意。 我没有什么可以比较的，但configuration和运行很简单。 现在它只能build立Win32 C ++项目和一个安装程序，但是我们正在移植到Linux上，它也应该可以工作。
获取Subversion版本库没有任何问题，并邮寄出警报等，我们喜欢它到目前为止。 再一次，我们对比较的经验有限。
我一直在使用CruiseControl.NET，TFS 2012和TeamCity 7.x几年，我相信TeamCity是最好的，因为它易于使用，舒适和信息丰富的用户界面和其他很酷的function，如构build依赖等等。 它只是工作，我喜欢它。
