连续集成策略-项目参考vs分支/合并
假设在遗留代码库(企业API)中有7个核心项目。代码库有大约50个引用一个或多个核心项目的应用程序。在50个应用程序中，只有几个在vss到tfs的手动迁移(手动don )后仍然工作。为了使应用程序再次工作，许多应用程序已经从企业API中删除，并被放入自己的TFS项目中。
我试图说服同事们，他们应该而不是，将其作为核心项目的一个分支，并将副本放在单独的TFS项目中，并且只在发布后将对核心项目的添加合并回企业API中。显然，当连续集成的频率较低时，它将更加困难。
我试图说服同事，最好将核心项目从企业API中删除，并将其放入自己的TFS项目中，然后引用bin/Debug。
是更好地将分支复制以分离TFS项目，然后合并(并在最后看到冲突)，还是更好地封装核心项目并强制一个20人的团队只使用每个核心项目的一个副本？
回答 2
Stack Overflow用户
发布于 2011-11-23 14:50:21
我确信您希望让您的团队引用已经构建的核心API二进制文件。重用的正确粒度，是发行版(一个版本化的构建)的粒度--参见Robert .Martin的96版C++报告以及我们在这里的解释：http://www.urbancode.com/html/resources/articles/reuse-maturity-model.html
基本上，球队似乎处于恐慌之中，只是做了最简单的事情，才能让他们回来并能够完成任务。这种方法是可以理解的，但我认为最好是他们承认，最好让他们的公共库成为共享的代码库，并且重用代码而不是dll是不好的，并且随着事情的稳定，需要解决的技术债务也是坏的。
Stack Overflow用户
发布于 2011-11-23 08:51:07
这取决于共享代码的成熟度。我想说的是，你可以遵循三种方法，每种方法各有优缺点：
选项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 &需要这些更改快速反映到所有受影响的应用程序中。
它还意味着，如果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和选项3是相似的，由著名的辩论“项目与文件引用”隔开。有关SO资源，请参阅这里，可以通过搜索获得更多信息。
如果您的核心项目是由于不断的更改和/或单元测试覆盖率低，那么您应该选择选项2(或3)。
如果你对他们的质量有信心的话，选择1是个不错的选择，因为这将大大提高你的整体生产力。
不了解您的产品及其质量，只需根据您提供的相当大的数量(20人，50个解决方案，7个核心项目)，我将选择2/3。
另一个重要的提示是:共享项目没有任何分离测试的方法，这种情况经常发生。如果是这种情况，而且Core项目没有自己的单元测试，没有专门的测试计划等等，那么除了选项1之外，什么都做没有意义。
关于这件事的另一个重要资源是ALM护林员的工作。
https://stackoverflow.com/questions/8235551
复制相似问题
腾讯云开发者
