为新的云应用组织 Visual Studio Team Services

Question

对于为新的云应用组织 Visual Studio Team Services 是否有任何指导方针和最佳实践？我计划为 REST 服务创建一个 WebAPI 解决方案、一个用于移动客户端的 Xamarin Forms 解决方案、一个用于 Web 的 MVC 解决方案，最后是 SQL 脚本。理想情况下，我想用自己的源代码来说明未来的应用程序。

Dev
     App1
           WebAPI
           XamarinForms
           MVC
           SQL
     App2
           ...
     ...
Test
Prod

另一种方法是为每个 App 创建一个项目

App1
     Dev
          WebAPI
          XamarinForms
          MVC
          SQL
      Test
          ...
      Prod
          ...
 App2
 ...

我还看到人们将所有东西都放在一个单独的集合下的一个巨大项目中。因此，我们不会在第一棵树中创建 Dev、Test、Prod 项目，而是将它们创建为文件夹。与第二棵树相同。为什么我不想创建多个团队项目？

我不是 TFS 专家，但我想从正确的角度开始。

附：我在 SO 上看到了一些类似的问题，但认为他们没有回答我的问题，尤其是关于不创建团队项目的部分。

Answer 1

Visual Studio Team Services（和本地 Team Foundation Server）支持团队项目集合、团队项目和团队的概念。

TPC 是最高程度的分离。目前，您在 VSTS 上获得一个 DefaultCollection。在此集合中，您可以创建单独的团队项目。在一个团队项目中，您有一个或多个团队。

当前的最佳实践表明，单个团队项目最容易使用。简而言之，这使您可以更轻松地共享代码、工作项和其他资产，同时仍然拥有单独的积压和代码存储库。

有关更详细的解释，请参阅有关此主题的一些博客，例如：

• Why You Should use a Single (Giant) TFS Team Project
• One Team Project to rule them all
• Many Git Repositories, but one Team Project to rule them all

在您的场景中，我绝对会使用一个团队项目，然后为每个单独的应用程序使用多个团队。然后，您可以在顶级团队中安排 Epics and Features 并将其分发给实施团队。

如果我今天开始这样的项目，我也会选择 Git 进行源代码控制。 Git 和 TFVC 都受支持，而 TFVC 无处可去。然而，Git 确实有我认为非常有吸引力的some advantages。

关于您的文件夹结构。如果 App1 和 App2 需要一起发布，它们应该位于共享分支中。如果它们可以单独发布，它们应该有自己的分支。

ALM Rangers 有一个关于版本控制的精彩文档，其中解释了不同的分支模型。这是freely available on CodePlex。