Cruise Control .Net vs Team Foundation Build我们的团队正在建立夜间和持续集成版本。 我们拥有Team Foundation Server，可以使用Team Foundation Build。 我对CC.Net更加熟悉，并采用这种方式，但是管理层发现花在TFS上的所有钱都想使用。 关于CC.Net，我更喜欢的一点是通知的灵活性以及实现自定义脚本的便捷性。 如果您对这两种产品都有经验，那么您更喜欢哪个，为什么？ 我都用过。我想这取决于您的组织重视什么。 既然您熟悉CC Net，那么我就不多说了。您已经知道是什么使它酷。 我喜欢Team Foundation Build：
这是促使我深入了解Team Foundation Build的原因：
如果您所在的大型组织中有很多老板，他们的预算很大，而且喜欢上一份报告(不要误会我的意思，这具有巨大的价值)，或者您需要扩展到多机构建农场，我会喜欢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时，我们预计将进行转换 自07年6月以来，我们一直在使用CruiseControl.net，它对我们来说非常有用。最好的部分是，它很容易集成到SVN，这是一个非常出色的源代码控制提供商。 所以我们的设置是：
我们已经进行了一些重大的并行开发，分支和合并的经验非常丰富。如果您有选择，我会选择上面的设置！ |
