如何评估迁移到Team Foundation Server

我的开发团队目前在我们的工作流程中使用以下软件：

• 吉拉
• Bamboo（Atlassian持续集成）
• Greenhopper（Atlassian敏捷项目管理）
• 合流
• Git，托管在BitBucket上
• Visual Studio 2012

如您所见，我们在Atlassian生态系统中投入了大量资金。我们正在考虑转向TFS，以便获得高级Visual Studio集成的优点，例如代码审查，更重要的是Microsoft测试管理器。

我以前在TFS上的经验是在2005或2008年（我不记得了），尽管对我而言，对它的记忆很差，尽管不如我在ClearCase上的经历那么糟糕。

为了正确评估我们向TFS的迁移，我们应该考虑哪些标准？

马丁·福勒（Martin Fowler）进行的小规模调查充分说明了前几年的TFS状况。“危险”是正确的。（我认为这是指无法识别VS外部所做的更改的方式，因此您可以创建WCF项目，然后使用外部svcutil工具创建客户端，然后检查所有更改。.但是TFS将很高兴忽略您的客户更改，因为它们不是在VS中进行的。

你要算成本：VS所需的版本，以获得的好东西-代码评审，例如，要求高级版是显著如果您通过MSDN获得VS更加昂贵。同样，非VS用户也可以访问系统，但是如果他们想要完整的访问权限而不是缩小的Web视图，则必须为他们提供CAL。TFS的总体成本可能很高。甚至是最近的Forrester报告（由Microsoft委托，因此您必须在这句话之间仔细阅读）说TFS需要大量的管理支持-需要2位顾问和6位管理员（他们花费了25％的时间）为他们对122位用户的案例研究提供支持（与这122位用户的4.5位管理员合作。与我在日常工作中设置并维护完整的SVN解决方案相比，这是很多东西）。TFS可以花很多精力来保持人们期望的工作。

根据我对TFS2012的经验（这是废话，不要忘记以前的版本），这是一个非常复杂的系统管理，尤其是如果您超出了预定义的设置。例如，如果您使用MSBuild来构建所有内容，那么就可以了。但是，例如，如果您有许多旧版本的.vdproj项目不受MSBuild支持，则必须编辑庞大的xaml构建脚本以使其构建这些项目。经过几天的工作之后，我能做的最好的事情就是通过将解决方案传递给devenv来重建解决方案，即使那样，也无法将生成结果输出到生成摘要中。使用NUnit进行测试的其他团队也得到了类似的结果-如果您使用内置的MSTest，则它可以工作。否则，您将被塞满。

作为用户，我发现集成更麻烦。我更喜欢TortoiseSVN，并且我几乎通过它完成了所有的SCM工作（因为它是一个很棒的工具）。使用TFS，您最终会在VS内部为每个操作创建一个新屏幕。因此，您的环境中为团队资源管理器提供了一个新选项卡，为构建提供了一个新选项卡，对于要查看的每个构建摘要也提供了一个新选项卡（如果要查看构建的详细信息，例如一个错误，点击太多链接）。我发现使用TFS时打开的文档数量超过了源文件！

签入同样适用，提交更改需要通过单击VS中“待更改”窗格上的几个选项卡来分配工作项并为签入添加注释。这是一件很小的事情，但是当我习惯于使用更简化的工具时，我感到很烦。

扩展构建系统是我发现的另一个不足。由于存在xaml配置，很难在构建中添加新功能，并且很难将这些功能的结果显示到构建屏幕中，或者是不可能的。因此，如果您喜欢添加诸如代码复杂性或静态分析之类的东西，或者甚至喜欢通过硒或部署进行自动测试等，那就算了吧。除非您在这些方面使用Microsoft工具（例如fxcop）。

更新工作流程是另外一个小问题-尽管强大的玩具提供了极大的帮助，但是正确设置工作流程仍然很尴尬，而且您仍然无法使用您真正想看到的信息来配置Scrum板-再一次，您将获得默认值或什么都没有。

合并也很痛苦，我认为MS为TFS采用git是一个很好的理由（请注意，这仅适用于全新的TFS项目，不能从TFS转换为git后端）。

因此，总的来说，它的工作效果还不错，但是我发现许多其他工具都更好。这些工具的缺点是它们没有完全集成在一起，但是恕我直言，这是一种优势，因为您可以选择所需的最佳钻头。使用TFS，您几乎可以得到别人想要您拥有的东西。如果您认为TFS中的错误系统不佳（我想您会发现），那么您将很难改用另一种系统。

应该将TFS与其他大型的全生命周期工具一起考虑。大多数开发人员讨厌这样的事情，因为他们不喜欢这些工具最终对他们施加的限制。

不过，我会尝试一下，下载30天试用版并安装。在评估时，请记住要在此处和此处进行一些更改，不要仅将其用于源代码签入，带必需工作项的签入并根据该工作项获取报告。尝试将签入分配给多个工作项，并尝试根据需要将工作项组合在一起。尝试将不同的东西合并到构建系统中，了解如何从报告服务中获取每日进度报告，将文档链接到工作流需求，并通过错误分类对它进行跟踪以进行编码以进行构建以进行重做然后发布。分支并合并很多。如果您不能轻松地完成所有这些事情，那么您最好还是坚持使用git。如果您不利用TFS的大多数ALM功能，那么使用TFS没有太多意义。

我已经从一家拥有大量Atlassian堆栈（和Mercurial）的公司转移到了一个拥有大量TFS堆栈的公司。我发现有两个烦恼。

首先是源代码控制。

当您习惯了DVCS时，切换回CVCS会很痛苦。TFS尤其让人痛苦，因为要使所有集成正常工作，它必须始终连接到服务器。

但是，值得庆幸的是，Microsoft最近允许将Git版本控制集成到TFS堆栈的其余部分中。因此，您无需放弃Git，并且我建议您不要放弃，因为每个人都已经知道这一点。

我还不确定代码审查工具对Git的性能如何，因为它似乎非常依赖架子集（有点像隐藏东西，但功能不那么强大）。但是，依靠架子集进行代码审查本身就很痛苦，因为它会阻止常规提交。

另一个烦恼是大多数人不考虑退出TFS的原因：Visual Studio Integration。

我还没有弄清楚其背后的认知推理，但是根据我的经验（考虑到这是普遍的），习惯于TFS的人们喜欢这种集成。他们不喜欢在IDE之外迁移任何东西。

另一方面，我一年后还没有变暖。与将构建服务器放在一个浏览器选项卡中，将票据放在另一个浏览器选项卡中等等相比，我发现它混乱且难以导航。（编辑：如Andrei所述，有一个Web界面，但是当您习惯于Jira和Jenkins的较新版本时，它也是令人费解的。但是，它至少现在可以在IE以外的浏览器中使用。因此就是这样。）

除非我尝试进行构建，否则我从不看构建，然后发现很难找到其他人是否已经在构建。除非要求我进行审查，否则我看不到其他人的更改。

但是，您的里程可能会有所不同。正如我所说，有些人似乎认为它是必不可少的。我只是不禁注意到，通常是人们从未以其他方式做到这一点。

另外，请注意这是2个负数，在相当大的基础架构中，其中2个负数可能是个人的。我的大部分经验是好的，TFS并不像某些人所相信的那样糟糕。而且大多数您发现所缺少的东西都可以打开（这是非常可配置的）。考虑到您要移动的是整个团队，而不是一个人，那么您可能会发现阻力较小。

我在使用TFS 2012方面有非常积极的经验。设置和运行TFS服务器非常容易，CI构建自动化非常简单明了（Gated检入构建非常棒。我们未能实现相同的功能与团队城市）。团队互动也非常透明和直接。您可以轻松地将签入与TFS工作项关联，管理积压，跟踪缺陷，进行代码审查等。甚至还有一个Messenger内置=）

但是请记住，如果您习惯JIRA的工作流程，则设置TFS工作流程可能是一项艰巨的任务。我建议采用一种预定义的TFS工作流程。另外，由于TFS中没有内置Wiki，因此您必须保留Confluence的知识库或切换到SharePoint。

如果您订阅了MSDN（我相信大多数使用MS技术栈的开发公司都拥有TSDN），则TFS便宜得多。在这种情况下，您可以免费使用TFS。

如果您所有的开发人员都在使用Visual Studio，我认为没有理由继续使用辅助工具。TFS提供了集成，健壮但易于使用的ALM系统。如果您有任何问题，我会很乐意回答您。

人们应该知道，TFS不仅仅是VCS，它还是ALM。

似乎许多人只想要VCS，但选择TFS是错误的方式。
对于CVCS，我仍然更喜欢SVN。
对于单独或开源，请务必使用GIT。

但是TFS2012还不错，然后在SVN上容易理解。
而团队基础服务是免费提供给5个用户/无限的私人回购。

客户端也是免费的，TFS浏览器基于VS2010构建，并且是免费的。
对于Eclipse，它具有Eclipse插件-到处都是TFS。

我认为没有任何成本问题。
TFS Express（免费）可以与SQL Server Express（也免费）一起使用。