Question

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

我试图说服同事他们应该不制作核心项目的分支，并将副本放在单独的TFS项目中，并且只在将核心项目的添加合并到企业API之后发布到PROD。显然，当频率较低时，连续整合会更加困难。

我试图说服同事，最好将核心项目从企业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版本中设置一旦您在CoreProject中签入后所有应用程序都开始构建。
您必须将团队项目本地映射到约定（否则编译将中断）

如果您不断更改CoreProject＆amp;需要将这些更改快速反映到所有受影响的应用程序。
这也意味着如果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中的更改时，都需要为每个受影响的应用程序组织合并。这需要付出一定的努力，但是您可以在自己的操场上稳定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构建的二进制输出签入到每个应用程序中。
只有在您确信CoreApplication是稳定的时才建议使用此方法。你不需要定期调试它。

基本上是选项2＆amp;选项3是类似的，由众所周知的辩论“项目与文件参考”分开。有关SO资源，请参阅here，可以通过搜索检索更多内容。

如果您的核心项目由于不断变化和/或单位测试覆盖率较低，您应该选择选项2（或3）。
如果您对其质量有信心，那么选择1是很好的选择，因为它将大大提高您的整体生产力。

如果您对产品及其质量一无所知，只需根据您提供的相当大的数量（20人，50个解决方案，7个核心项目），我会选择2/3选项。

另一个重要提示：共享项目不会经常发生分离测试。如果是这种情况并且核心项目没有自己的单元测试，没有专门的测试计划等，那么除了选项1之外别无其他。

此问题的另一个重要资源是ALM游侠的work。

Answer 2

我很确定您希望让您的团队引用已构建的核心API二进制文件。正确的重用粒度是发布的粒度（版本化的版本），请参阅96的Robert C Martin的C ++报告以及我们在此处的解释：http://www.urbancode.com/html/resources/articles/reuse-maturity-model.html

基本上，似乎团队处于恐慌状态，只做最简单的事情，可以让他们恢复并能够交付。这条路线是可以理解的，但我认为最好是他们承认最好将他们的公共图书馆作为共享代码库，并且重用代码而不是dll是坏的，并且技术债务要在事情稳定时加以解决。

持续集成战略 - 项目参考与分支/合并

2 个答案: