具有分支依赖的分支项目的 TFS 策略答案

【问题标题】：TFS Strategy For Branched Project With A Branched Dependancy具有分支依赖的分支项目的 TFS 策略
【发布时间】：2017-08-17 03:35:39
【问题描述】：

我已经对如何处理我的问题进行了大量研究，但我似乎无法掌握我想要做什么。更重要的是，我需要创建一个我的团队其他成员能够相对轻松地遵循的解决方案。我尝试过的解决方案适用于单个开发人员，但会导致团队成员之间产生混淆。

我目前有一个像这样的分支结构：

项目名称
- 主要
  - 演示项目
  - DemoEntityFramework
- 质量保证
  - 演示项目
  - DemoEntityFramework
- 开发
  - 演示项目
  - DemoEntityFramework

我想提取 DemoEntityFramework 并以相同的方式（Main/QA/Dev）对其进行分支。我需要它分支的原因是因为分支之间的数据库结构不同是很常见的。因此，当指向 EntityFramework 的 PROD 版本时，QA 将无法正确构建。退出它的另一个原因是因为我有其他项目依赖于相同的框架，我可以重用该库，而不必在这些项目中保留实体框架的其他副本。

我看到有人建议使用 NuGet 来处理依赖关系。我可以接受，但我需要一种方法让每个分支在合并时都拉取各自的依赖项而不会中断。

【问题讨论】：

标签： entity-framework tfs continuous-integration

【解决方案1】：

最好的解决方案是使用 NuGet 来处理您的情况下的依赖关系。您可以在 NuGet Config File 中为每个分支定义不同的包源。

<packageSources>
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" />
    <add key="MyRepo - ES" value="http://MyRepo/ES/nuget" />
</packageSources>

您可以为每个分支创建不同的 NuGet 存储库，为每个分支创建不同的 NuGet 配置文件，并在该配置文件中简单地定义正确的存储库 URL。

如果您不喜欢使用 Nuget，则希望将所有依赖程序集保存在团队项目中分支外部的文件夹中。为了确保相对引用不会中断，您必须让所有分支在团队项目中处于相同的文件夹深度。无论程序集文件夹是否分支，都应正确创建相对引用。更多详细信息请参考这个炉排博客：Project Dependencies will break with branching if not done properly

【讨论】：

我会不会不签入 NuGet 配置文件？或者确保它不会被合并？如果文件被合并，那么它将再次破坏引用。我将仔细查看您提供的链接，它看起来很有希望，但经过快速浏览后，我看不出如何解决分支依赖项的问题。我的分支项目处于相同的深度，因此我可以轻松引用相同的 DLL，但不能轻松引用位于不同文件夹中的 DLL。它们处于相同的深度，但位于不同的文件夹中：Dev/Main/QA
如果我可以设置某种变量来提取分支名称。我可以将它插入到相对路径中，这样就可以修复它。
@Cory 您需要检查 NuGet 配置文件，并且在合并/分支时应小心。你可以参考这个类似的：stackoverflow.com/questions/12864330/…这是目前最好的方法，可惜没有完美的解决方案。毕竟你也做了相当多的研究。此外，我们通常不分支程序集文件夹。如果我的回复对您有所帮助或给了您正确的方向，您可以mark it as an answer，这也有助于社区中的其他人。
现在标记为答案。我想先给一些时间来回答其他问题。我看过那个帖子，可能不得不求助于类似的东西。感谢您的帮助。
我实际上找到了另一种方法来完成我想要的。感谢您的建议，但我发现的方式似乎在配置最少的情况下效果最佳。

【解决方案2】：

我将这个答案包括在内，因为它是一种与正常方法不同的方法，但它似乎最适合我的情况。

我真的很喜欢 NuGet 方法，但我真的不喜欢 NuGet 配置之间存在差异的想法。有人很容易意外地在分支之间合并该文件，并防止在整个分支上进行合并。

我已经在我的项目中定义了不同的配置来对连接字符串等进行转换。我真的希望有一种方法可以对项目引用做同样的事情。结果是there is a way。根据选择的配置，我现在可以让它指向不同的 DLL 路径。即使他们不在同一个层次结构中。现在，我只是根据配置指向适当的分支。

这是我在 .csproj 中更改的示例

<ItemGroup Condition="'$(Configuration)' != 'Dev'">
  <Reference Include="MyReference, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
    <HintPath>C:\Example\Prod\MyReference.dll</HintPath>
    <Private>True</Private>
  </Reference>
</ItemGroup>
<ItemGroup Condition="'$(Configuration)' == 'Dev'">
  <Reference Include="MyReference, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
    <HintPath>C:\Example\Dev\MyReference.dll</HintPath>
    <Private>True</Private>
  </Reference>
</ItemGroup>

【讨论】：

【解决方案3】：

一段时间过去了，随着时间的推移，我们的策略也随之而来。如果您愿意，我一直在研究更好的编程“标准”，并且遇到了依赖注入。我一直都知道这件事，甚至过去也曾涉足过。但我只是触及了表面。

我们的新方法有点像 Patrick-MSFT 提到的 Nuget。除了现在，我已将各个区域的每个不同 EF 项目组合成一个解决方案，并在每次成功构建时部署到 Nuget。

然后，在我的“DemoProject”中，我使用依赖注入（构造函数注入）将适当的 EF 上下文（包装在存储库中）传递给控制器/类/等。

这样做，我现在可以将我的项目从需要担心 EF 项目中解脱出来。这进一步有助于我们的源代码控制和持续部署。

【讨论】：