We've been using CruiseControl.net since June '07 and it's worked great for us. Best part, it integrates to SVN easily which is a far superior source control provider.
Trac - for bug reports and project management (integrates perfectly with SVN)
nunit - for unit testing
We've had some major parallel development going and the branching and merging experience was spectacular. If you have the choice I'd go with the setup above!
SVN is an OK tool far superior is not true, SVN vs. TFS is similar to a Ford pickup vs a Mercedes 500, it gets the job done but it isnt pretty nor is it comfortable, the merging has a lot to be desired. I prefer the TFS merging tool as it seems like the branching dev is right there working with you, that is how smart it is. Our internal SVN seemed to get corrupted a lot, this is the reason we ditched it and went to TFS and have not looked back. The shelving of changesets is wonderful for an agile development shop, currently have 270+ engineers on TFS with no issues or problems, SVN simply was not capable of handling that kind of load without someone having issues.
I prefer CC.NET simply because of tools we have developed in house to extend the functionality in reporting and administration. TFS build is very closely integrated however and we anticipate a switch when we upgrade to SQL 2008
I'm assuming that as you own TFS you'll be using it for version control. In that case I would lean towards Team Foundation Build. That said, I pretty much agree with Nick.
I wrote the CruiseControl.NET integration for TFS. It works fine and gives you the same build capabilities that you are used to. To me, CC.NET's main advantage is that it is completely extensible and has integrations with all the major SCM and build systems under the sun. The main reason I wrote the CC.NET integration to TFS it is that in TFS2005 the build system did not have out-the-box CI support. However the TFS2008 version is much improved and the team continue to very actively improve it for future releases of TFS.
The main reason for switching to TFS Build would be so that it automatically reports the build information back into TFS which helps complete the software development picture in terms of reporting. It also integrates nicely with the work item tracking side of TFS and inside the IDE (both in Visual Studio and Eclipse).
That said, if you have large investments in Nant scripts that do more than just compile and test your code or you already have a home-brewed reporting solution you might want to stick with what you have.
报告。 所有相关的构建结果（包括测试）都存储在 SQL 数据库中，并通过 SQL Server Reporting Services 报告。 这是一个非常强大的工具，用于绘制随时间变化的构建和测试结果图表。 CC Net 没有内置此功能。
您可以通过 MSBUILD 进行类似的自定义。 它与使用 NAnt 和 CC Net 基本相同
以下是让我对 Team Foundation Build 感到困惑的原因：
要构建 C++/CLI 项目（或运行单元测试...？），构建代理必须具有安装了 VSTS Dev 或 Team Suite。 朋友们，这简直太疯狂了。
它必须连接到 TFS Mothership
如果您在一个大型组织中，有很多老板，他们有巨额预算并且喜欢报告（不要误会我的意思，这具有巨大的价值），或者您需要扩展到多个-机器构建农场，我更喜欢 Team Foundation Build。
如果您是一家精益型商店，请坚持使用 CC Net 并发展您自己的报告解决方案。 这就是我们所做的。
直到我们被收购。 并得到了 TFS :P
I've used both. I guess it depends on what your organization values.
Since you are familiar with CC Net, I won't speak much to that. You already know what makes it cool.
Here's what I like about Team Foundation Build:
Build Agents. It's very simple to turn any box into a build machine and run a build on it. MSFT got this one right.
Reporting. All relevant build results (test included) are stored in a SQL database and reported on via SQL Server Reporting Services. This is an immensely powerful tool for charting build and test results over time. CC Net doesn't have this built in.
You can do similar customizations via MSBUILD. It's basically the same as using NAnt with CC Net
Here's what drives me up the wall about Team Foundation Build:
To build C++/CLI projects (or run unit tests...?) the build agent must have VSTS Dev or Team Suite installed. This, friends, is just batsh*t crazy.
It must be connected to the TFS Mothership
If you're in a big org with lots of bosses who have huge budgets and love reports (and don't get me wrong, this has huge value) OR you need to scale up to a multi-machine build farm, I'd prefer Team Foundation Build.
If you're a leaner shop, stick with CC Net and grow your own reporting solutions. That's what we did.
发布评论
评论（5）
自 2007 年 6 月以来，我们一直在使用 CruiseControl.net，它对我们来说非常有效。 最好的部分是，它可以轻松集成到 SVN，这是一个非常优秀的源代码控制提供商。
所以我们的设置是：
我们正在进行一些主要的并行开发，分支和合并体验非常出色。 如果您可以选择，我会选择上面的设置！
We've been using CruiseControl.net since June '07 and it's worked great for us. Best part, it integrates to SVN easily which is a far superior source control provider.
So our setup is:
We've had some major parallel development going and the branching and merging experience was spectacular. If you have the choice I'd go with the setup above!
Team Foundation Build 的真正价值在于它将变更集和工作项与构建相关联。
这实现了一些有用的场景：
然后当然还有构建的报告此信息的顶部。 但即使这些链接本身对于非管理类型也很有用。
请访问 www.tfsbuild.com 了解不同 Team Build 配置的“秘诀”。
The real value in Team Foundation Build is that it associates changesets and work items with builds.
This enables a couple of useful scenarios:
Then of course there's the reports built on top of this information. But even these links by themselves are useful to non-management types.
Have a look at www.tfsbuild.com for "recipes" on different Team Build configurations.
SVN 是一个还不错的工具，远超它，但事实并非如此，SVN 与 TFS 的比较类似于福特皮卡与梅赛德斯 500 的比较，它可以完成工作，但它不漂亮也不舒服，合并还有很多需要改进的地方。 我更喜欢 TFS 合并工具，因为分支开发人员似乎就在那里与您一起工作，这就是它的智能程度。 我们的内部 SVN 似乎被严重损坏，这就是我们放弃它并转向 TFS 并且没有回头的原因。 变更集的搁置对于敏捷开发车间来说非常好，目前 TFS 上有 270 多名工程师，没有任何问题或问题，SVN 根本无法在没有人出现问题的情况下处理这种负载。
我更喜欢 CC.NET，只是因为我们内部开发了工具来扩展报告和管理的功能。 然而，TFS 构建非常紧密地集成，我们预计升级到 SQL 2008 时会发生切换
SVN is an OK tool far superior is not true, SVN vs. TFS is similar to a Ford pickup vs a Mercedes 500, it gets the job done but it isnt pretty nor is it comfortable, the merging has a lot to be desired. I prefer the TFS merging tool as it seems like the branching dev is right there working with you, that is how smart it is. Our internal SVN seemed to get corrupted a lot, this is the reason we ditched it and went to TFS and have not looked back. The shelving of changesets is wonderful for an agile development shop, currently have 270+ engineers on TFS with no issues or problems, SVN simply was not capable of handling that kind of load without someone having issues.
I prefer CC.NET simply because of tools we have developed in house to extend the functionality in reporting and administration. TFS build is very closely integrated however and we anticipate a switch when we upgrade to SQL 2008
我假设您拥有 TFS，因此您将使用它进行版本控制。 在这种情况下，我会倾向于 Team Foundation Build。 也就是说，我非常同意 Nick 的观点。
我编写了TFS 的 CruiseControl.NET 集成。 它运行良好，并为您提供与您习惯的相同的构建功能。 对我来说，CC.NET 的主要优点是它是完全可扩展的，并且与所有主要的 SCM 和构建系统集成。 我将 CC.NET 集成编写到 TFS 的主要原因是，在 TFS2005 中，构建系统没有现成的 CI 支持。 然而，TFS2008 版本有了很大改进，团队将继续非常积极地改进它以用于 TFS 的未来版本。
切换到 TFS Build 的主要原因是它会自动将构建信息报告回 TFS，这有助于在报告方面完成软件开发情况。 它还与 TFS 的工作项跟踪端以及 IDE 内部（在 Visual Studio 和 Eclipse 中）完美集成。
也就是说，如果您对 Nant 脚本进行了大量投资，而这些脚本的作用不仅仅是编译和测试代码，或者您已经拥有自制的报告解决方案，那么您可能希望坚持使用现有的解决方案。
I'm assuming that as you own TFS you'll be using it for version control. In that case I would lean towards Team Foundation Build. That said, I pretty much agree with Nick.
I wrote the CruiseControl.NET integration for TFS. It works fine and gives you the same build capabilities that you are used to. To me, CC.NET's main advantage is that it is completely extensible and has integrations with all the major SCM and build systems under the sun. The main reason I wrote the CC.NET integration to TFS it is that in TFS2005 the build system did not have out-the-box CI support. However the TFS2008 version is much improved and the team continue to very actively improve it for future releases of TFS.
The main reason for switching to TFS Build would be so that it automatically reports the build information back into TFS which helps complete the software development picture in terms of reporting. It also integrates nicely with the work item tracking side of TFS and inside the IDE (both in Visual Studio and Eclipse).
That said, if you have large investments in Nant scripts that do more than just compile and test your code or you already have a home-brewed reporting solution you might want to stick with what you have.
我都用过。 我想这取决于您的组织的价值观。
既然大家都熟悉CC Net，我就不多说了。 您已经知道什么让它很酷。
以下是我喜欢 Team Foundation Build 的地方：
以下是让我对 Team Foundation Build 感到困惑的原因：
如果您在一个大型组织中，有很多老板，他们有巨额预算并且喜欢报告（不要误会我的意思，这具有巨大的价值），或者您需要扩展到多个-机器构建农场，我更喜欢 Team Foundation Build。
如果您是一家精益型商店，请坚持使用 CC Net 并发展您自己的报告解决方案。 这就是我们所做的。
直到我们被收购。 并得到了 TFS :P
I've used both. I guess it depends on what your organization values.
Since you are familiar with CC Net, I won't speak much to that. You already know what makes it cool.
Here's what I like about Team Foundation Build:
Here's what drives me up the wall about Team Foundation Build:
If you're in a big org with lots of bosses who have huge budgets and love reports (and don't get me wrong, this has huge value) OR you need to scale up to a multi-machine build farm, I'd prefer Team Foundation Build.
If you're a leaner shop, stick with CC Net and grow your own reporting solutions. That's what we did.
Until we got acquired. And got TFS :P