在TFS解决方案之间共享代码

Question

我有几个不同的应用程序，我需要在两者之间共享代码以减少维护。我一直试图在stackoverflow和web上阅读很多，这是一个相当普遍的问题;我还没有找到我喜欢的答案。

我们的TFS分支结构就是这样。我们有三个分公司开发，主要和生产。在开发分支上，所有积极的开发工作都已完成，当我们完成开发新功能时，我们将其与Main结合，然后再进行生产。生产分支始终是服务器上运行的代码。如果我们发现在下一次迭代之前必须解决的错误。这些更改主要完成，并在部署时与生产合并。需要共享代码的应用程序不共享共同的分支层次结构或共同的迭代时间表。事实上，其中一个应用程序每年只进行一次一个月的迭代。 （我知道这从做它的传统方式略有不同

在我的研究，我发现了几个不同的解决方案，但我有问题，所有的人都

二进制共享：。 其中常见的我发现的方法是将编译后的二进制文件分支到开发分支下的文件夹中，我的问题是如果我们在共享代码中检测到必须快速修复的错误，那么就会编译出有问题的代码。我们会得到所有修改到共享代码库的bug。

项目共享： 我的主要问题在于它如何能够e以可接受的方式。我最初的想法是当新的迭代开始时，将主分支中的更改与共享代码合并以更新它。将main与开发分支合并，以更新开发分支，并修改错误引起的更改。并将共享代码的新版本更新到开发分支中。但从我的理解，这是不支持的TFS，因为我会创建嵌套分支。

我的问题是： 如何在解决方案之间共享几个常见项目，同时保持它们的独立性，并且能够修复主分支上的错误而不用担心常见的项目发生了变化，因此引入了新的错误。但仍然能够修复常见项目中的错误并将这些修复合并回共享的常见项目中。

Answer 1

谢谢大家对我们的所有帮助，因为你们中的一些人对我的最终解决方案做出了贡献，我选择了发布我最终在这里做的事情。

我最终什么事做的是二进制共享和代码共享

对于经常更新，并与相对快速的迭代我引用我需要共享的项目，创造项目的指导方针，以确保代码是向后项目兼容特定的时间量。

对于更新频率较低的项目，我在编译的二进制文件中进行了分支。我还创建了版本化的共享项目并创建了指南，以确保任何向后兼容性冲突的代码导致版本号主要组件的增量。

Answer 2

我所做的是所谓的“二进制共享”的一个版本。如果您可以将您的共享代码视为第三方项目，那么您可以应用相同的规则进行开发，以便您从运行良好的第三方项目中获得期望。这意味着您应该专门版本共享代码（与semVer或类似的东西）并尽可能保持向后兼容性。

是的，您是对的，这意味着如果您在共享代码中发现错误，则需要发布另一个版本，然后重新编译依赖于此代码的项目。

但是，这也意味着如果只依赖共享代码的两个项目中的一个需要修复错误，那么只有该项目需要采用新版本。

另一个好处是，它是由项目当采取更新。因此，您可以更自信地管理错误修复过程。

所以，我的建议是为共享代码创建一个新的TFS项目，给它所有对第三方项目（它自己的版本，NuGet等）显示的爱，然后将构建程序集放入要使用它的项目的库文件夹中。

希望这会有所帮助。

Answer 3

虽然问题不尽相同，但我认为答案可能与this one一致。