巡航控制.NET vs Team Foundation构建[关闭]

既然你熟悉CC网,我就不多说了。你已经知道是什么让它很酷了。

以下是我喜欢Team Foundation构建:

• 构建代理。将任何框转换为构建机器并在其上运行构建非常简单。MSFT做对了。
• 报告。所有相关的构建结果(包括测试)都存储在SQL数据库中,并通过SQL Server Reporting Services进行报告。这是一个非常强大的工具,用于绘制随时间变化的构建和测试结果。CC Net没有内置此功能。
• 您可以通过MSBUILD进行类似的自定义。它基本上与将NAnt与CC Net一起使用是一样的

下面是我对团队基金会建设的看法:

• 要构建C++/CLI项目(或运行单元测试…?),构建代理必须安装VSTS Dev或Team Suite。朋友们,这太疯狂了。
• 它必须连接到TFS母舰

如果您是一家更精简的公司,请坚持使用CC Net,并发展您自己的报告解决方案。我们就是这么做的。

直到我们被收购。得到TFS:P

我假设当您拥有TFS时,您将使用它进行版本控制。在这种情况下,我倾向于Team Foundation Bug。尽管如此,我非常同意你的观点 Nick .

CruiseControl.NET integration for TFS . 它工作得很好,并为您提供了与以前相同的构建功能。对我来说,CC.NET的主要优势在于它是完全可扩展的,并且与所有主要的SCM和sun下的构建系统集成。我将CC.NET集成编写到TFS的主要原因是,在TFS2005中,构建系统没有现成的CI支持。然而,TFS2008版本有了很大的改进,团队继续非常积极地改进它,以备将来发布TFS。

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

这就是说,如果您在Nant脚本上有大量投资,而这些脚本不仅仅是编译和测试代码,或者您已经有了一个自制的报告解决方案,那么您可能希望继续使用现有的解决方案。

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

这提供了两个有用的场景:

• 您可以查看构建并查看它包含哪些代码更改(和工作项)

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

请访问www.tfsbuild.com了解不同团队构建配置的“配方”。

SVN是一个很好的工具远比TFS优越不是真的,SVN与TFS类似于福特皮卡与梅赛德斯500,它完成了任务,但它既不漂亮也不舒适,合并还有很多需要改进的地方。我更喜欢TFS合并工具,因为它看起来就像分支开发人员正在与您一起工作,这就是它的智能所在。我们的内部SVN似乎被破坏了很多,这就是为什么我们放弃了它,去了TFS,没有回头看。变更集的搁置对于敏捷开发车间来说非常好,目前TFS上有270多名工程师,没有任何问题,SVN根本无法在没有问题的情况下处理此类负载。

我更喜欢CC.NET,因为我们在内部开发了一些工具来扩展报告和管理的功能。不过,TFS构建是非常紧密集成的,我们预计在升级到SQL 2008时会发生切换

因此,我们的设置是:

• Cruise Control.Net
• SVN
• Trac
• nunit-用于单元测试

我们已经进行了一些主要的并行开发,分支和合并的经历非常壮观。如果你有选择,我会选择上面的设置!