我们目前正在为.NET开发设置源代码控制/构建/更多服务器，我们正在考虑使用Team Foundation Server（需要花费很多成本）或者将几个组合在一起开源选项，如SourceForge Enterprise / GForge和Subversion以及CruiseControl.net等。有没有人走在完全成熟的OSS之路上，或者只有当你想要做到并且很快就能开始工作时，它是TFS吗？
答案 0 :(得分：5)
我的工作目前主要是使用Cruise Control作为引擎的OSS构建过程，这很棒。我建议如果你不知道为什么你需要TFS，那可能不值得花费。
你需要记住OSS的东西是这个软件已经被Java工作人员使用多年，或者软件是类似Java代码的端口。它坚固耐用，适合用途。
微软无法发布OSS代码，这就是他们必须重新实现大量开源内容的原因。所以，不，没有必要，并且已经有数百万个项目在该堆栈上发布。另一方面，你可以通过TFS获得很多很好的功能，你不会（轻松地）使用OSS堆栈，例如与你的bug /功能跟踪软件集成。
答案 1 :(得分：4)
我总是采用OSS方式，从未遇到过问题。我还强烈推荐TeamCity用于您的CI解决方案。有一个免费的许可证，我认为它使CC.NET脱离了水，以便于配置和反馈。
答案 2 :(得分：3)
我已经成为TFS的日常用户已有大约1。5年了。
答案 3 :(得分：2)
如果您使用的是TFS，请确保安装VSTS2008SP1。我看过投诉的绝大多数人都在使用2005版。 2005年是经典的“微软1.0”综合症。后来的两个“版本”已经解决了很多问题。
2008 Service Pack不仅仅是一个错误修复 - 而是添加了许多新功能。
就OSS的选择而言 - 有很多讨论（在这里和其他地方）。它不是一个廉价的产品 - 但它是许多场景的最佳选择（对其他场景来说是最差的）。
答案 4 :(得分：2)
我们查看了TFS，但最终选择了Subversion + Trac + VisualSVN。我们现在不做CI，但我认为Cruisecontrol将是我们使用的。
我开始将Trac用于众多开源项目，这非常棒。它实际上只是TFS的一部分，所以你必须在那里做出决定 - 如果你使用了所有东西，TFS可能会更好地将它们捆绑在一起。 Trac是一个wiki / bug跟踪器/源浏览器。一切都是链接的 - 当您在提交消息中键入WikiPage的名称或说“修复错误＃1234”时，只要您在Trac中看到该消息，链接就会转到正确的位置。它通常是帮助您完成工作但却不受影响的工具。
VisualSVN是TortoiseSVN（Subversion客户端）和VisualStudio之间的桥梁，极大地提高了工作效率。他们有免费试用，之后不是很贵（50美元/用户），但非常值得。
Trac的一个可能的缺点是在Windows世界中，在IIS上工作是一件痛苦的事。我已多次安装Trac，但很快就试图让它正常工作而感到沮丧。我最终在不同的IP上安装Apache（也可以使用不同的端口）然后它是无缝的。
除了我团队中的一个人（他们有一点点经验），之前没有人曾经使用过颠覆。一对夫妇使用了VSS，就是这样。每个人都持怀疑态度，但我会说在几天之内他们都是皈依者。在完全学习Trac并习惯了所有事情（几天之后）之后，每个人都被完全卖掉并喜欢它。
答案 5 :(得分：1)
Subversion + Cruisecontol.Net是一个不错的选择。 SVN功能丰富，稳定，灵活。
答案 6 :(得分：1)
我们公司使用CruiseControl / SVN / nAnt / JIRA组合取得了巨大成功。
TFS的交易破坏者只对大公司来说是值得的。对于拥有30个或更少开发人员的小型公司来说，这将是非常昂贵的，这已经从上述开源组合中获益匪浅。
答案 7 :(得分：1)
与单独的OS工具集相比，使用TFS的真正好处是可用的各种信息流的集成。
*创建一个要求并插入到TFS中
*创建一组将它们链接到需求的任务，并将它们分配给各个开发人员
*每个开发人员都在处理他的任务并签入，将任务分配给检查的变更集
*进入错误修复程序，在这种情况下，更改集将与错误修复请求协调，您还可以将错误修复映射到原始要求
完成此操作后，所有信息都可用于跟踪项目并对工作进行评估，例如错误修复导致的更改数量，这些更改产生了更多错误或更改请求等等。
所有这些信息在中型和大型组织中都非常有用，而且从我现在看到的情况来看，跟踪集成不同操作系统工具是不可能的（或非常困难）。
答案 8 :(得分：1)
TFS堆栈远不止源控制和CI /夜间构建设置。想想项目管理，错误报告，这些都不仅仅是CruiseControl，SVN和NAnt。只是报告本身可能值得投资。还要记住，如果您是MSDN订户/ ISV黄金合作伙伴/等。你可以免费获得一些......
答案 9 :(得分：1)
我最近才开始每天开始使用TFS，并且来自之前开源的堆栈，我发现它非常缺乏。
虽然所有错误和任务跟踪的集成是一个非常好的功能，但负面因素不会给它带来负担。
就个人而言，我使用以下堆栈，它为我提供了从企业规模的持续集成到自动部署所需的一切，而成本只是其中的一小部分：
答案 10 :(得分：0)
如果您确切知道自己需要什么，我会强烈赞同使用TFS。基于OSS的廉价或免费插件如Visual SVN和TestDriven.Net非常好，以至于与VS的集成已经是无缝的。
答案 11 :(得分：0)
我认为我会投入一个新的视角，可以用一点点盐，因为我还没有尝试过，但我打算在即将开展的项目中使用Bitten来进行CI。这是在Trac + SVN上运行的，这两个工具都是我成功用于许多项目的。
答案 12 :(得分：0)
我们已逐步建立了一个开发堆栈，我们目前正在使用：
答案 13 :(得分：0)
我已经看到了两个都在行动（虽然我是一个Java开发人员）。选择和混合方法的好处是你可以为所有东西选择最好的位（例如，我会查看Hudson的CI - 它非常适合Java，也适用于.Net并且加载插件，非常简单易用）。缺点是你必须自己完成所有的集成。但是，这在Java世界中更容易获得 lot 。另外，不要让人们告诉你支持的产品更好。在这个领域的许多OSS产品中，质量非常好，您可以从cimmunity获得更好的支持，而不是等待供应商支持合同的答案（IBM，我在看着你）
希望这有帮助。
答案 14 :(得分：0)
我认为TFS对于上述帖子中提到的所有额外功能都是值得的。它的连续构建功能严重缺乏，所以我们使用CruiseControl.NET增强了这一部分，这是非常棒的。如果我们现在就选择反对TFS的唯一原因是我们正在转向我们产品的跨平台开发。所以，如果您已经考虑过这一点，请考虑OSS。 Subversion / Trac将是我最喜欢的组合，CruiseCOntrol.NET仍然是骨干。使用mono的CC.NET在Linux和Mac上运行良好。
答案 15 :(得分：0)
TFS2010有一个TFS Basic，它不需要任何费用（超过你的msdn订阅/ visual studio许可证）。 每个VS许可证限制为1，但您只需要非VS用户的其他许可证
VS2010中的UI自动化使得TFS成为将开源解决方案拼凑在一起的胜利者
答案 16 :(得分：0)
值得一提的是，广泛的TFS功能的最佳替代方案不一定是OSS，而是低预算的商业广告，例如用于代码质量和架构探索的NDepend，用于代码覆盖的NCover， TestDriven.NET用于嵌套在IDE中的测试...