tfs - 持续集成策略 - 项目引用与分支/合并

Question

假设您在遗留代码库(企业 API)中有 7 个核心项目。代码库大约有 50 个应用程序引用了一个或多个核心项目。在手动进行的 vss 到 tfs 迁移之后，50 个应用程序中只有几个仍然可以工作。为了让应用程序再次运行，许多应用程序已从企业 API 中取出并放入其自己的 TFS 项目中。

我试图说服同事他们应该不是 创建核心项目的一个分支并将副本放在单独的 TFS 项目中，并且只有在发布到 PROD 后才将核心项目的新增内容合并回企业 API。显然，当持续集成不那么频繁时，它会更加困难。

我试图说服同事最好将核心项目从企业 API 中取出并将它们放在他们自己的 TFS 项目中，然后引用 bin/Debug。

是分支更好，复制分支以分离 TFS 项目然后合并(并在最后看到冲突)还是更好地封装核心项目并强制一个 20 人的团队只使用每个核心的一个副本项目？

Answer 1

这实际上取决于您共享代码的成熟度。我想说您可以遵循三种方法，每种方法都有自己的优点和缺点:

选项 1:直接从他们自己的团队项目中引用它们

Team Project Application 1
-->  Development
        --> ...
-->  MAIN
        --> Sources
            --> Application 1
                --> Application1.sln

Team Project Application 2
-->  Development
        --> ...
-->  MAIN
        --> Sources
            --> Application 2
                --> Application1.sln

Team Project CoreProject 1
-->  Development
        --> ...
-->  MAIN
        --> Sources
            --> CoreProject1.csproj

使用这种方法，您可以在 CI 构建中进行设置，以便在您 checkin CoreProject 后让所有应用程序开始构建。
您必须使用约定在本地映射团队项目(否则编译会中断)

如果您不断更改 CoreProject 并需要将这些更改快速反射(reflect)到所有受影响的应用程序，这是一个很好的方法。这也意味着您可以承受某个应用程序的不稳定性，如果 CoreProject 中的重大更改造成了它。

选项 2:通过分支间接引用它们

Team Project Application 1
-->  Development
        --> ...
-->  MAIN
        --> SharedSources
            --> CoreProject1_branch
                --> CoreProject1.csproj
        --> Sources
            --> Application 1
                ---> Application1.sln

Team Project Application 2
-->  Development
        --> ...
-->  MAIN
        --> SharedSources
            --> CoreProject1_branch
                --> CoreProject1.csproj
        --> Sources
            --> Application 2
                ---> Application1.sln

Team Project CoreProject 1
-->  Development
        --> ...
-->  MAIN
        --> Sources
            --> CoreProject1.csproj

使用这种方法，每次在 CoreProject1 中 checkin 更改时，您都需要对每个受影响的应用程序进行合并。这带来了一定的努力，但让您有时间在自己的操场上稳定 CoreProject，然后将其合并到您的应用程序中。这种方法意味着您还有每个 CoreProject 的构建定义。一般来说，如果您重视 CoreProject 的稳定性，并且在更改引起麻烦时不能“污染”您的应用程序，那么这是一个很好的方法。顺便说一句，这是我们采用的方法。

选项 3:在每个应用程序中进行文件引用

Team Project Application 1
-->  Development
        --> ...
-->  MAIN
        --> SharedBinaries
            --> CoreProject1_branch
                --> CoreProject1.dll
        --> Sources
            --> Application 1
                ---> Application1.sln

Team Project Application 2
-->  Development
        --> ...
-->  MAIN
        --> SharedBinaries
            --> CoreProject1_branch
                --> CoreProject1.dll
        --> Sources
            --> Application 2
                ---> Application1.sln

Team Project CoreProject 1
-->  Development
        --> ...
-->  MAIN
        --> Sources
            --> CoreProject1.csproj

使用这种方法，您需要将 CoreApplication 构建的二进制输出 checkin 每个应用程序。仅当您确信 CoreApplication 是稳定的并且您不需要定期调试它时才建议这样做。

基本上选项 2 和选项 3 是相似的，由著名的辩论“项目与文件引用”分开。见 here对于 SO 资源，可以通过搜索检索更多内容。

如果您的核心项目是由于不断变化和/或单元测试覆盖率低，您应该选择选项 2(或 3)。如果您对它们的质量有信心，则选择选项 1 是一个不错的选择，因为它将大大提高您的整体生产力。

如果不了解您的产品及其质量，仅根据您提供的相当多的人数(20 人、50 个解决方案、7 个核心项目)，我会选择选项 2/3。

另一个重要提示:共享项目没有任何分离测试手段的情况经常发生。如果是这种情况，并且 Core Projects 没有自己的单元测试、没有专门的测试计划等，那么除了选项 1 之外做任何其他事情都没有意义。

关于此事的另一个重要资源是 work由 ALM 护林员。