CruiseControl.NET - 设置起来可能有点麻烦（大多数 CI 系统也是如此），但值得坚持使用。目前，我已将其设置为在完成构建后运行单元测试，并按需生成 Wix 安装程序。正如丹所说，它看起来有点过时，但这并不重要，因为它为您提供了大量易于获取和阅读的信息。
一件事 - 确保所有开发人员都安装了 CC Tray，正在运行并指向他们的构建。在通知托盘中看到“另一个成功构建”的感觉真是太棒了。
CruiseControl.NET - it can be a bit of a pain to set up (as can most CI systems), but it is worth perservering with. I currently have it set up to run unit tests on completion of builds, and to produce Wix installers on-demand. As Dan said, it looks a bit dated, but that doesn't matter, as it provides you with plenty of information that's easy to get at and easy to read.
One thing - make sure all your developers have CC Tray installed, running and pointing to their builds. It's a great feeling to get "Another successful build" in your notification tray.
We're using ccnet at work, which is fine for most of our needs (we have about 50 automated builds), but it needs one person for full time tweaking and fixing.
If you're starting from scratch, please take a look at Bamboo. We have looked into it and it looks really promising, but it doesn't completely match our needs and we have invested way too much time in ccnet to switch to Bamboo now.
I inherited a luntbuild server. Not a good option for a .NET project. If you find that you're constantly falling back to using the build server to run generic command line tasks, then something is wrong. A good build server had a good understanding of unit tests output and msbuild tasks as more than opaque commands to be run when the source control system changes.
I'm fairly new to the CI-scene and I've been concentrating my efforts on CruiseControl.NET, using NAnt and Ivy to build my .NET projects.
I've found that CruiseControl.NET is very adaptable to lots of other tools, such as NCover/NUnit/etc. They all plug into this and integrate the results for a combined build process.
I'll be looking into TeamCity in the near future for my own interest, but I think that CruiseControl does a good job, but only as good as your build-scripts! If these are pants, then your builds can only be expected to be that good.
But in summary, CruiseControl.NET is a good solution, but I'm yet to find out how good the competition is in comparison.
We're happy with Hudson. I don't have anything to compare it to, but it was simple to configure and get running. Right now it only builds Win32 C++ projects and an installer, but we're porting to Linux and it should work with that as well.
Gets Subversion repositories without any problems and mails out alerts, etc. We like it so far. Again, we have limited experience with comparisons.
I've been working with CruiseControl.NET, TFS 2012 and TeamCity 7.x for several years and i believe TeamCity is the BEST due to it's ease of use, comfortable and informative UI and other cool features like build dependencies and many more. It just works, I love it.
但我认为重要的是要提前了解您想要包含在 CI 系统中的内容的范围。它只是构建还是要引入其他元素，例如静态分析、跨项目依赖关系、部署、功能测试等。为了帮助进行规划，我在 企业 CI 元素（PDF；无需注册）。请不要让“E 字”让您望而却步；我只是指除了基本的快速反馈 CI 构建之外的东西。 :)
它不是特定于工具的，但列出了您在规划/评估阶段时可能考虑的各种实践。
No question like this is complete without a link to the big CI Feature Matrix(Web Archive) which lists just about every CI option out there.
But I think it is important to look ahead to the scope of what you want to include in your CI system. Is it going to be just builds or are you going to be bringing in other elements like static analysis, cross-project dependencies, deployments, functional tests, etc. To help with that planning I created this wallchart on the Elements of Enterprise CI (PDF; no registration required). Please don't let the "E-word" put you off; I just mean stuff beyond the basic fast feedback CI build. :)
It isn't tool specific but lists a variety of practices you might consider while you're in the planning/evaluation stages.
TeamCity has a wonderful feature of allowing the developer to perform a personal build before committing. Very useful!
CruiseControl.NET is the granddaddy of the bunch and is hence a little dated visually etc. As it has been around for a while, Google knows how to fix many issues you will come up against.
For these reasons (amongst others), I use CruiseControl.NET at work and TeamCity at home and in my open source life :)
I'm a CruiseControl.NET user all the way. My teams uses it at work and I use it at home for personal projects.
In particular, CruiseControl.NET allows me to run through the whole CI process: builds, version update, unit and integration tests, archival of source or release candidate, code coverage, even deployment to our test system at work. It's highly customizable, works well with MSBuild and NAnt, and even had an extensible plug-in architecture.
It pretty much does everything I need.
The biggest disadvantage: configuration is sometimes a pain, and can take time. But once it's done, it's done, and as another poster said, I love seeing the "successful build" signal because I know that not only did the build itself work, but that also that my unit and integration tests all ran successfully.
We use Hudson at work. The main reason is, that it is very easy to setup. You can directly execute the war (it's a executable jar) or deploy it at any servlet-container. And you're ready to start. Also Hudson supports many tools and is extensible through it's plugin-system.
我们从 CruiseControl.NET 切换到 TeamCity 主要是因为配置方便。 TeamCity 还具有更多功能，但主要原因是漂亮的 Web UI 比 XML 配置文件更易于使用。
编辑：TeamCity 可以开箱即用地完成大多数任务；必要时我们使用 NAnt。
We switched from CruiseControl.NET to TeamCity primarily because of ease of configuration. TeamCity also has more features, but the main reason was that a nice Web UI is simpler to use than XML configuration files.
EDIT: Most tasks TeamCity will do out of the box; when necessary we use NAnt.
发布评论
评论（13）
CruiseControl.NET - 设置起来可能有点麻烦（大多数 CI 系统也是如此），但值得坚持使用。目前，我已将其设置为在完成构建后运行单元测试，并按需生成 Wix 安装程序。正如丹所说，它看起来有点过时，但这并不重要，因为它为您提供了大量易于获取和阅读的信息。
一件事 - 确保所有开发人员都安装了 CC Tray，正在运行并指向他们的构建。在通知托盘中看到“另一个成功构建”的感觉真是太棒了。
CruiseControl.NET - it can be a bit of a pain to set up (as can most CI systems), but it is worth perservering with. I currently have it set up to run unit tests on completion of builds, and to produce Wix installers on-demand. As Dan said, it looks a bit dated, but that doesn't matter, as it provides you with plenty of information that's easy to get at and easy to read.
One thing - make sure all your developers have CC Tray installed, running and pointing to their builds. It's a great feeling to get "Another successful build" in your notification tray.
我们在工作中使用 ccnet，这可以满足我们的大多数需求（我们有大约 50 个自动化构建），但它需要一个人来全职调整和修复。
如果您是从头开始，请看看 Bamboo。我们已经研究过它，它看起来确实很有前途，但它并不完全符合我们的需求，而且我们在 ccnet 上投入了太多时间，现在转向了 Bamboo。
问候，
塞巴斯蒂安
We're using ccnet at work, which is fine for most of our needs (we have about 50 automated builds), but it needs one person for full time tweaking and fixing.
If you're starting from scratch, please take a look at Bamboo. We have looked into it and it looks really promising, but it doesn't completely match our needs and we have invested way too much time in ccnet to switch to Bamboo now.
Regards,
Sebastiaan
我继承了一个luntbuild服务器。对于 .NET 项目来说这不是一个好的选择。如果您发现自己不断地退回到使用构建服务器来运行通用命令行任务，则说明出现了问题。一个好的构建服务器对单元测试输出和 msbuild 任务有很好的理解，因为在源代码控制系统发生更改时，要运行的不仅仅是不透明的命令。
我很享受迁移到 Team City 的过程。
I inherited a luntbuild server. Not a good option for a .NET project. If you find that you're constantly falling back to using the build server to run generic command line tasks, then something is wrong. A good build server had a good understanding of unit tests output and msbuild tasks as more than opaque commands to be run when the source control system changes.
I'm enjoying migrating to Team City.
我对 CI 场景相当陌生，我一直将精力集中在 CruiseControl.NET 上，使用 NAnt 和 Ivy 构建我的 .NET 项目。
我发现 CruiseControl.NET 非常适合许多其他工具，例如 NCover/NUnit/等。它们都插入其中并集成组合构建过程的结果。
出于我自己的兴趣，我将在不久的将来研究 TeamCity，但我认为 CruiseControl 做得很好，但只能与您的构建脚本一样好！如果这些是裤子，那么你的身材只能期望那么好。
但总而言之，CruiseControl.NET 是一个很好的解决方案，但我还没有发现相比之下竞争对手有多好。
I'm fairly new to the CI-scene and I've been concentrating my efforts on CruiseControl.NET, using NAnt and Ivy to build my .NET projects.
I've found that CruiseControl.NET is very adaptable to lots of other tools, such as NCover/NUnit/etc. They all plug into this and integrate the results for a combined build process.
I'll be looking into TeamCity in the near future for my own interest, but I think that CruiseControl does a good job, but only as good as your build-scripts! If these are pants, then your builds can only be expected to be that good.
But in summary, CruiseControl.NET is a good solution, but I'm yet to find out how good the competition is in comparison.
我们对 Hudson 感到满意。我没有任何东西可以与它进行比较，但它的配置和运行很简单。目前它仅构建 Win32 C++ 项目和安装程序，但我们正在移植到 Linux，它也应该可以使用。
毫无问题地获取 Subversion 存储库并发出警报等。我们非常喜欢它远的。同样，我们的比较经验有限。
We're happy with Hudson. I don't have anything to compare it to, but it was simple to configure and get running. Right now it only builds Win32 C++ projects and an installer, but we're porting to Linux and it should work with that as well.
Gets Subversion repositories without any problems and mails out alerts, etc. We like it so far. Again, we have limited experience with comparisons.
我多年来一直使用 CruiseControl.NET、TFS 2012 和 TeamCity 7.x，我相信 TeamCity 是最好的，因为它易于使用、舒适且信息丰富的 UI 以及其他很酷的功能（如构建依赖项等）。它确实有效，我喜欢它。
I've been working with CruiseControl.NET, TFS 2012 and TeamCity 7.x for several years and i believe TeamCity is the BEST due to it's ease of use, comfortable and informative UI and other cool features like build dependencies and many more. It just works, I love it.
如果没有链接到大CI 功能矩阵（网络存档），其中列出了几乎所有 CI 选项。
但我认为重要的是要提前了解您想要包含在 CI 系统中的内容的范围。它只是构建还是要引入其他元素，例如静态分析、跨项目依赖关系、部署、功能测试等。为了帮助进行规划，我在 企业 CI 元素（PDF；无需注册）。请不要让“E 字”让您望而却步；我只是指除了基本的快速反馈 CI 构建之外的东西。 :)
它不是特定于工具的，但列出了您在规划/评估阶段时可能考虑的各种实践。
No question like this is complete without a link to the big CI Feature Matrix(Web Archive) which lists just about every CI option out there.
But I think it is important to look ahead to the scope of what you want to include in your CI system. Is it going to be just builds or are you going to be bringing in other elements like static analysis, cross-project dependencies, deployments, functional tests, etc. To help with that planning I created this wallchart on the Elements of Enterprise CI (PDF; no registration required). Please don't let the "E-word" put you off; I just mean stuff beyond the basic fast feedback CI build. :)
It isn't tool specific but lists a variety of practices you might consider while you're in the planning/evaluation stages.
没有什么帮助：
编辑：Jonik 在评论中指出，我错过了 Java 项目的 Hudson 和 CruiseControl 之间有什么区别？ 和如何以及为何设置 C# 构建机器？ 。您会找到非常有见地的答案。换句话说，我认为您要寻找的所有内容都已经在 Stack Overflow 上。
Nothing helpful in:
EDIT: A pointed out by Jonik in a comment, I missed What is the difference between Hudson and CruiseControl for Java projects? and How and why do I set up a C# build machine?. You'll find very insightful answers. In other words, I think that everything you're looking for is already on Stack Overflow.
TeamCity 有一个很棒的功能，允许开发人员在提交之前执行个人构建。非常有用！
CruiseControl.NET 是这群人的鼻祖，因此在视觉上等方面有点过时。由于它已经存在了一段时间，Google 知道如何解决您会遇到的许多问题。
由于这些原因（除其他外），我在工作中使用 CruiseControl.NET，在家里和我的开源生活中使用 TeamCity :)
TeamCity has a wonderful feature of allowing the developer to perform a personal build before committing. Very useful!
CruiseControl.NET is the granddaddy of the bunch and is hence a little dated visually etc. As it has been around for a while, Google knows how to fix many issues you will come up against.
For these reasons (amongst others), I use CruiseControl.NET at work and TeamCity at home and in my open source life :)
我一直都是 CruiseControl.NET 用户。我的团队在工作中使用它，我在家里用于个人项目。
特别是，CruiseControl.NET 允许我运行整个 CI 流程：构建、版本更新、单元和集成测试、源代码或候选版本的归档、代码覆盖率，甚至部署到我们工作中的测试系统。它具有高度可定制性，与 MSBuild 和 NAnt 配合良好，甚至还具有可扩展的插件架构。
它几乎可以满足我需要的一切。
最大的缺点：配置有时很痛苦，并且需要时间。但一旦完成，就完成了，正如另一位海报所说，我喜欢看到“成功构建”信号，因为我知道不仅构建本身有效，而且我的单元和集成测试都成功运行。
I'm a CruiseControl.NET user all the way. My teams uses it at work and I use it at home for personal projects.
In particular, CruiseControl.NET allows me to run through the whole CI process: builds, version update, unit and integration tests, archival of source or release candidate, code coverage, even deployment to our test system at work. It's highly customizable, works well with MSBuild and NAnt, and even had an extensible plug-in architecture.
It pretty much does everything I need.
The biggest disadvantage: configuration is sometimes a pain, and can take time. But once it's done, it's done, and as another poster said, I love seeing the "successful build" signal because I know that not only did the build itself work, but that also that my unit and integration tests all ran successfully.
Team Foundation Build 也是一个选项因为它与 Team Foundation Server 交互得很好。只要您获得 TFS 许可，它就是免费的。
Team Foundation Build is an option as well as it interacts very well with Team Foundation Server. It's free as long as long you've licensed TFS.
我们在工作中使用 Hudson。主要原因是，它非常容易设置。您可以直接执行 war（它是一个可执行 jar）或将其部署在任何 servlet 容器中。现在您已经准备好开始了。此外，Hudson 支持许多工具，并且可以通过其插件系统进行扩展。
We use Hudson at work. The main reason is, that it is very easy to setup. You can directly execute the war (it's a executable jar) or deploy it at any servlet-container. And you're ready to start. Also Hudson supports many tools and is extensible through it's plugin-system.
我们从 CruiseControl.NET 切换到 TeamCity 主要是因为配置方便。 TeamCity 还具有更多功能，但主要原因是漂亮的 Web UI 比 XML 配置文件更易于使用。
编辑：TeamCity 可以开箱即用地完成大多数任务；必要时我们使用 NAnt。
We switched from CruiseControl.NET to TeamCity primarily because of ease of configuration. TeamCity also has more features, but the main reason was that a nice Web UI is simpler to use than XML configuration files.
EDIT: Most tasks TeamCity will do out of the box; when necessary we use NAnt.