Cruise Control .Net与Team Foundation Build

Question

我们的团队正在建立夜间和持续的集成构建。我们拥有Team Foundation Server，可以使用Team Foundation Build。我对CC.Net更熟悉并且倾向于这种方式，但管理层看到了花在TFS上的所有资金，并希望使用它。

我更喜欢CC.Net的一些事情是通知的灵活性以及实现自定义脚本的简易性。

如果您有这两种产品的经验，您更喜欢哪种产品？为什么？

Answer 1

我用过两者。我想这取决于你的组织的价值观。

由于您熟悉CC Net，我不会说太多。你已经知道是什么让它变得很酷。

以下是我喜欢的Team Foundation Build：

• 构建代理。将任何盒子变成构建机器并在其上运行构建非常简单。 MSFT得到了这个。
• 报告。所有相关的构建结果（包括测试）都存储在SQL数据库中，并通过SQL Server Reporting Services进行报告。这是一个非常强大的工具，可用于绘制构建和测试结果。 CC Net没有这个内置。
• 您可以通过MSBUILD进行类似的自定义。它与使用带有CC Net的NAnt
基本相同

以下是关于Team Foundation Build的重要信息：

• 要构建C ++ / CLI项目（或运行单元测试......？），构建代理必须安装VSTS Dev或Team Suite。朋友们，这真是太棒了。
• 必须连接到TFS Mothership

如果你是一个拥有大量预算和爱情报告的老板的大型组织（并且不会误解我的意思，这具有巨大价值）或者您需要扩展到多机构建农场，我更喜欢Team Foundation Build。

如果您是一个更精简的商店，请坚持使用CC Net并发展自己的报告解决方案。这就是我们所做的。

直到我们被收购。得到了TFS：P

Answer 2

我假设您拥有TFS，您将使用它进行版本控制。在那种情况下，我会倾向于Team Foundation Build。那就是说，我非常赞同Nick。

我写了CruiseControl.NET integration for TFS。它工作正常，并为您提供与以往相同的构建功能。对我来说，CC.NET的主要优势在于它完全可扩展，并且与所有主要的SCM集成并在阳光下构建系统。我将CC.NET集成到TFS的主要原因是在TFS2005中，构建系统没有开箱即用的CI支持。然而，TFS2008版本得到了很大改进，团队继续非常积极地为未来的TFS版本进行改进。

切换到TFS Build的主要原因是它会自动将构建信息报告回TFS，这有助于在报告方面完成软件开发图片。它还可以很好地与TFS的工作项跟踪端和IDE内部（在Visual Studio和Eclipse中）集成。

也就是说，如果您对Nant脚本进行大量投资，而不仅仅是编译和测试您的代码，或者您已经拥有自制的报告解决方案，那么您可能希望坚持使用所拥有的内容。

Answer 3

Team Foundation Build的真正价值在于它将变更集和工作项与构建相关联。

这可以实现几个有用的场景：

• 您可以查看工作项并找出
中包含的构建内容
• 您可以查看构建并查看其中包含的代码更改（和工作项）

当然，这些报告建立在这些信息之上。但即使这些链接本身对非管理类型也很有用。

在www.tfsbuild.com上查看不同Team Build配置中的“食谱”。

Answer 4

SVN是一个好的工具远远不是真的，SVN与TFS类似于福特皮卡与梅赛德斯500相比，它完成了工作，但它不漂亮也不舒服，合并有很多是期望。我更喜欢TFS合并工具，因为看起来分支开发工具就在那里与你合作，这就是它的智能。我们的内部SVN似乎被腐蚀了很多，这就是我们抛弃它并前往TFS并且没有回头的原因。变更集的搁置非常适合敏捷开发商店，目前在TFS上有270多名工程师没有任何问题或问题，SVN根本无法在没有人遇到问题的情况下处理这种负载。

我更喜欢CC.NET，因为我们内部开发的工具可以扩展报告和管理功能。但是，TFS构建非常紧密集成，我们预计在升级到SQL 2008时会出现转换

Answer 5

自2007年6月以来，我们一直在使用CruiseControl.net，它对我们来说非常有用。最好的是，它很容易集成到SVN，这是一个非常优秀的源控制提供商。

所以我们的设置是：

• Cruise Control.Net
• SVN
• Trac - 用于错误报告和项目管理（与SVN完美集成）
• nunit - 用于单元测试

我们已经进行了一些重要的并行开发，并且分支和合并体验非常壮观。如果您有选择，我会选择上面的设置！