我们的团队正在设置夜间和持续集成构建。我们拥有 Team Foundation Server，可以使用 Team Foundation Build。我更熟悉 CC.Net 并以这种方式精益求精，但管理层看到了花在 TFS 上的所有资金并希望使用它。
我更喜欢 CC.Net 的一些地方是通知的灵活性以及实现自定义脚本的简易性。
如果您对这两种产品都有经验，您更喜欢哪一种，为什么？
whatknott
问问题
12134 次
5 回答
30
我都用过。我想这取决于您的组织的价值观。
既然你对CC Net很熟悉，我就不多说了。你已经知道是什么让它很酷了。
以下是我喜欢 Team Foundation Build 的地方：
- 构建代理。将任何盒子变成构建机器并在其上运行构建非常简单。MSFT 做对了。
- 报告。所有相关的构建结果（包括测试）都存储在 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
于 2008-09-17T05:16:03.920 回答
13
我假设当您拥有 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 脚本进行了大量投资，而不仅仅是编译和测试您的代码，或者您已经拥有自制的报告解决方案，您可能希望坚持现有的。
于 2008-09-17T06:23:21.307 回答
5
Team Foundation Build 的真正价值在于它将变更集和工作项与构建相关联。
这实现了几个有用的场景：
- 您可以查看一个工作项并找出它包含在什么构建中
- 您可以查看构建并查看其中包含哪些代码更改（和工作项）
当然还有建立在这些信息之上的报告。但即使这些链接本身对非管理类型也是有用的。
查看 www.tfsbuild.com 以获取有关不同 Team Build 配置的“食谱”。
于 2008-09-17T07:21:36.970 回答
4
SVN 是一个好工具，远远优于不是真的，SVN 与 TFS 类似于福特皮卡与梅赛德斯 500，它完成了工作，但它并不漂亮，也不是很舒服，合并有很多不足之处。我更喜欢 TFS 合并工具，因为分支开发人员似乎就在那里与您一起工作，这就是它的智能。我们内部的 SVN 似乎损坏了很多，这就是我们放弃它并转到 TFS 并且没有回头的原因。变更集的搁置对于敏捷开发商店来说非常棒，目前在 TFS 上有 270 多名工程师没有任何问题或问题，SVN 根本无法在没有人遇到问题的情况下处理这种负载。
我更喜欢 CC.NET 仅仅是因为我们内部开发了一些工具来扩展报告和管理的功能。但是，TFS 构建非常紧密地集成在一起，我们预计在升级到 SQL 2008 时会进行切换
于 2009-04-28T17:36:04.000 回答