多个项目的源代码结构

Question

背景：

3-5个程序员与TFS一起工作。我们支持遗留应用程序，也支持构建新应用程序。我正在实施持续交付的要素，我希望一开始就有一个良好的结构。目前，应用程序之间的相互依赖性很小，但在未来，将会有一些共享组件。

我计划实现“单一主干”分支策略(换句话说，不进行分支)，除非非常罕见地需要一个长特性分支--我将努力确保这种情况永远不会发生。

问题：

考虑到这一点，哪种源代码结构更好，为什么呢？对选择一个而不是另一个(工作区等)有什么实质性影响吗？

单主支路

$/MAIN/src/ApplicationA/ApplicationA.sln
$/MAIN/src/ApplicationA/Project1.csproj
$/MAIN/src/ApplicationA/Project2.csproj
$/MAIN/src/ApplicationB/...
$/MAIN/src/SharedModule/...

对每个应用程序的主分支

$/ApplicationA/MAIN/src/ApplicationA.sln
$/ApplicationA/MAIN/src/Project1.csproj
$/ApplicationA/MAIN/src/Project2.csproj
$/ApplicationB/MAIN/src/...
$/SharedModule/MAIN/src/...

Answer 1

在我的经验中，我发现对于具有不同开发周期的事物，最好使用不同的分支。

如果您打算将它们作为一个包一起发布，并且将它们开发为一个单一的产品，那么单一的主分支更合适。

如果每个应用程序都可以在不同的时刻发布，那么每个应用程序的主分支似乎更合适。

Answer 2

我喜欢在一个主分支中开发所有的代码。然后使用配置设置从本质上禁用用于生产的模块，并启用该模块进行测试，直到它准备好发布为止。额外的好处是模块(Dll)已经打包用于发行版，因为您发布的时间较早，而且经常。