TFS 与开源替代方案？[关闭]
https://stackoverflow.com/questions/61959
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我们目前正在为 .NET 开发设置源代码控制/构建/以及更多服务器，我们正在考虑利用 Team Foundation Server（这会花费大量资金）或组合多个开源选项，例如 SourceForge Enterprise/GForge 以及 Subversion 和 CruiseControl.net 等。有没有人走过完整的 OSS 道路，或者只有当您想要正确使用并尽快开始工作时才使用 TFS？
解决方案
我的工作目前主要使用 OSS 构建流程，以 Cruise Control 作为引擎，这非常棒。我建议，如果您不知道为什么需要 TFS，那么它可能不值得付出代价。
对于 OSS 的东西，您必须记住的是，该软件要么已经被 Java 人员使用了很多年，要么该软件是类似 Java 代码的端口。它坚固耐用并且适合用途。
微软无法发布 OSS 代码，这就是为什么他们必须重新实现很多开源东西。所以，不，没有必要，并且已经有数百万个项目在该堆栈上交付。另一方面是，TFS 还提供了许多 OSS 堆栈无法（轻松）获得的优秀功能，例如与错误/功能跟踪软件集成。
其他提示
我一直走 OSS 的路，从来没有遇到过问题。我还强烈推荐 TeamCity 作为您的 CI 解决方案。有一个免费许可证，我认为它在配置和反馈方面比 CC.NET 更胜一筹。
我每天使用 TFS 已有大约 1.5 年了。
- 源头控制稳定
- 您无法轻松地在离线状态下工作。文件签出到服务器。
- 自动合并效果很好，但有时它会损坏源文件（编码问题）。
- TFS有一种迟钝的感觉！？尤其是测试经理。托管代码？
- 测试部分有各种愚蠢的错误，没什么关键的。
- 测试运行启动时间太长（待定）。
- 我偶尔会遇到 SQL 死锁！？
- 恕我直言，问题跟踪很糟糕。您被迫在缓慢的集成对话框中工作，网页仅显示。我建议将其与其他问题跟踪系统进行比较，例如 吉拉
- 构建工作正常。
如果您使用 TFS，请确保安装 VSTS2008SP1。我见过的绝大多数发表投诉的人都使用 2005 版本。2005年是典型的“微软1.0”综合症。后来的两个“版本”已经解决了很多问题。
2008 年 Service Pack 不仅修复了错误，还添加了许多新功能。
至于选择与 OSS - 有很多讨论（这里和其他地方）。它不是一个便宜的产品 - 但它是很多场景的最佳选择（对于其他场景来说是最糟糕的选择）。
我们研究了 TFS，但最终选择了 Subversion + Trac + VisualSVN。我们现在不做 CI，但我认为 Cruisecontrol 将是我们使用的。
我开始在许多开源项目中使用 Trac，它非常棒。它实际上只是 TFS 所做的一部分，因此您必须在那里做出决定 - 如果您使用所有内容，TFS 可能会更好地将它们结合在一起。Trac 是一个 wiki/bug 跟踪器/源代码浏览器。一切都是链接的 - 当您输入 WikiPage 的名称或在提交消息中说“Fix bug #1234”时，只要您在 Trac 中看到该消息，链接就会转到正确的位置。它是一种可以帮助您完成工作但通常不会妨碍您的工具。
VisualSVN 是 TortoiseSVN（Subversion 客户端）和 VisualStudio 之间的桥梁，极大地提高了工作效率。他们有免费试用，之后价格不是很贵（50 美元/用户），但非常值得。
Trac 的一个可能的缺点是在 Windows 世界中，在 IIS 上工作是一件痛苦的事情。我已经安装了 Trac 多次，但在尝试让它正常工作时很快就感到沮丧。我最终在不同的 IP 上安装了 Apache（也可以使用不同的端口），然后就可以无缝安装了。
除了我团队中的一个人（有一点点经验）之外，没有人以前使用过 subversion。一对夫妇使用过 VSS，仅此而已。每个人都非常怀疑，但我想说几天之内他们都皈依了。在完全学习 Trac 并习惯了一切（几天后）后，每个人都完全被迷住并喜欢它。
我们公司使用CruiseControl/SVN/nAnt/JIRA组合取得了巨大成功。
TFS 的缺点是只有大公司才值得这样做。对于拥有 30 名或更少开发人员的小型公司来说，这将是非常昂贵的，而这些公司已经从上述开源组合中受益匪浅。
Subversion + Cruisecontol.Net 是一个不错的选择。SVN功能丰富、稳定、灵活。
与一组单独的操作系统工具相比，使用 TFS 的真正好处是集成了各种可用信息流。
* 创建需求并插入TFS
* 创建一组将它们与需求联系起来的任务并将它们分配给各个开发人员
* 每个开发人员都处理他的任务并签入，将任务分配给签入的变更集
* 出现错误修复，同样在这种情况下，更改集将与错误修复请求协调，您还可以将错误修复映射到原始需求
完成此操作后，所有信息都可以用于跟踪项目并对工作进行评估，例如错误修复导致了多少更改，哪些要求生成了更多错误或更改请求等。
所有这些信息在中型和大型组织中都非常有用，并且从我现在所看到的情况来看，不可能（或非常困难）跟踪集成不同的操作系统工具。
TFS 堆栈不仅仅是源代码控制和 CI/夜间构建设置。想想项目管理、错误报告，所有这些加在一起就不仅仅是 CruiseControl、SVN 和 NAnt。仅凭这些报告就可能值得投资。另请记住，如果您是 MSDN 订阅者/ISV 黄金合作伙伴/等等。你可能会免费得到一些......
我已经看到了这两种方法的实际应用（尽管我是一名 Java 开发人员）。选择和混合方法的优点是您可以为所有内容选择最好的部分（例如我会检查 Hudson for CI - 它非常适合 Java，也适用于 .Net，并且具有 负载 插件并且使用起来非常简单）。缺点是您必须自己完成所有集成。然而，这正在得到一个 很多 在 Java 世界中更容易。另外，不要让人们告诉您受支持的产品更好。在这个领域的许多 OSS 产品中，质量都非常出色，您可以获得 更好的 来自 cimmunity 的支持，而不是等待供应商支持合同的答复（IBM，我在看着你）
希望这可以帮助。
我强烈同意这样的观点：只有当您确切地知道自己需要它做什么时，才值得使用 TFS。基于 OSS 的廉价或免费插件（如 Visual SVN 和 TestDriven.Net）非常好，与 VS 的集成已经是无缝的。
我想我应该提出一个可以半信半疑的新观点，因为我还没有尝试过，但我计划使用 被咬 用于即将进行的项目中的 CI。它运行在 Trac+SVN 之上，这两个很棒的工具我已经成功地用于许多项目。
我们已经在这里逐步建立了一个开发堆栈，目前我们正在使用：
- 颠覆
- 巡航控制
- RedMine（将错误跟踪与源代码控制集成在一起，包括 wiki、基本项目管理等）。
我认为 TFS 对于上述帖子中提到的所有额外功能来说是值得的。但它的持续构建功能严重缺乏，因此我们使用 CruiseControl.NET 来增强该部分，这非常棒。如果我们现在就这样做，我们会选择不使用 TFS 的唯一原因是我们正在转向产品的跨平台开发。因此，如果您考虑过这一点，请考虑 OSS。Subversion/Trac 将是我最喜欢的组合，而 CruiseCOntrol.NET 仍然是支柱。使用 mono 的 CC.NET 在 Linux 和 Mac 上运行良好。
TFS2010 有一个 TFS Basic，它不需要任何费用（除了您的 msdn 订阅/Visual Studio 许可证之外）。每个 VS 许可证仅限 1 个，但您只需要非 VS 用户的额外许可证
仅 VS2010 中的 UI 自动化就使 TFS 成为拼凑开源解决方案的赢家
