我们的团队正在建立夜间和持续集成版本。我们拥有Team Foundation Server，可以使用Team Foundation Build。我对CC.Net更加熟悉，并采用这种方式，但是管理层发现花在TFS上的所有钱都想使用。

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

如果我们对这两种产品都有经验，那么我们更喜欢哪个？为什么？

解决方案

回答

自07年6月以来，我们一直在使用CruiseControl.net，它对我们来说非常有用。最好的部分是，它易于集成到SVN中，后者是一个非常出色的源代码控制提供商。

所以我们的设置是：

• 巡航控制网
• SVN
• Trac-用于错误报告和项目管理(与SVN完美集成)
• nunit-用于单元测试

我们已经进行了一些重大的并行开发，分支和合并的经验非常丰富。如果我们有选择，我会选择上面的设置！

回答

我都用过。我想这取决于组织重视什么。

既然我们熟悉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母舰

如果我们所在的大型组织中有很多老板，他们的预算很大，而且喜欢上一份报告(不要误会我的意思，这具有巨大的价值)，或者我们需要扩展到多机构建农场，我会喜欢Team Foundation Build。

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

直到我们被收购为止。并获得了TFS：P

回答

我假设我们拥有TFS，然后将其用于版本控制。在这种情况下，我会倾向于Team Foundation Build。也就是说，我几乎同意尼克的看法。

我为TFS编写了CruiseControl.NET集成。它可以正常工作，并为我们提供与以前相同的构建功能。对我来说，CC.NET的主要优点是它是完全可扩展的，并且与所有主要的SCM和阳光下的构建系统集成在一起。我将CC.NET集成编写到TFS的主要原因是，在TFS2005中，构建系统没有现成的CI支持。但是，TFS2008版本已大大改进，并且团队将继续非常积极地对其进行改进，以用于将来的TFS版本。

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

就是说，如果我们对Nant脚本进行了大量投资，而Nant脚本不仅可以编译和测试代码，还可以使用自制的报告解决方案，那么我们可能希望坚持使用已有的代码。

回答

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

这启用了两个有用的方案：

• 我们可以查看一个工作项目并找出它包含在什么版本中
• 我们可以查看一个构建，并查看其包含哪些代码更改(和工作项)

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

请访问www.tfsbuild.com，以获取有关不同Team Build配置的"食谱"。

回答

SVN是一个可以接受的工具，远远优于事实，SVN vs. TFS与福特皮卡vs Mercedes 500相似，虽然可以完成工作，但它也不漂亮，也不舒适，合并有很多不足之处。我更喜欢TFS合并工具，因为分支开发人员似乎正与我们一起工作，这就是多么聪明。我们的内部SVN似乎已损坏很多，这就是我们放弃它并前往TFS并没有回头的原因。变更集的搁置对于敏捷开发商店来说是很棒的选择，目前TFS上有270多名工程师，没有任何问题，SVN根本没有能力解决这种负载。

我之所以喜欢CC.NET，仅仅是因为我们内部开发了一些工具来扩展报告和管理功能。 TFS构建非常紧密地集成在一起，但是我们预计在升级到SQL 2008时会进行切换