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.那就是说,我非常赞同尼克.

我为TFS编写了CruiseControl.NET集成.它工作正常,并为您提供与以往相同的构建功能.对我来说,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配置中的"食谱".