多个项目的源代码结构答案

【问题标题】：Source Code Structure for Multiple Projects多个项目的源代码结构
【发布时间】：2012-10-29 05:05:10
【问题描述】：

背景：

3-5 名程序员使用 TFS。我们支持旧版应用程序以及构建新应用程序。我正在实施持续交付的元素，我希望从一个好的结构开始。目前应用的相互依赖很少，但未来会有一些共享组件。

我计划实施“单主干”分支策略（换句话说，NO BRANCHING），除了极少数需要长功能分支的情况——我将努力确保永远不会发生这种情况。

问题：

鉴于此，哪种源代码结构更好，为什么？选择其中一个（工作区等）是否有任何实质性影响？

单一主分支

$/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/...

【问题讨论】：

标签： version-control tfs continuous-integration branching-and-merging continuous-deployment

【解决方案1】：

我喜欢在一个主分支中开发所有代码。然后使用配置设置基本上禁用模块进行生产并启用它进行测试，直到它准备好发布。额外的好处是模块 (dll) 已经为发布打包，因为您提前发布并且经常发布。

【讨论】：

【解决方案2】：

根据我的经验，我发现最好为具有不同开发周期的事物使用单独的分支。

如果您要始终将它们作为单个包一起发布，并且它们作为单个产品开发 - 单个主分支更合适。

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

【讨论】：