0

Background:

3-5 programmers working with TFS. We support legacy apps as well as build new apps. I am implementing elements of continuous delivery and I want to have a good structure to start with. At present there is very little interdependency of apps but in the future there will be some shared components.

I plan to implement a "single trunk" branching strategy (in other words, NO BRANCHING) except for the very rare case where a long feature branch is required -- which I will work to ensure never happens.

Question:

Given this, which source code structure is better and why? Are there any material impacts to choosing one over the other (workspaces, etc)?

SINGLE MAIN BRANCH

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

vs. MAIN BRANCH PER APPLICATION

$/ApplicationA/MAIN/src/ApplicationA.sln
$/ApplicationA/MAIN/src/Project1.csproj
$/ApplicationA/MAIN/src/Project2.csproj
$/ApplicationB/MAIN/src/...
$/SharedModule/MAIN/src/...
kingdango
  • 3,979
  • 2
  • 26
  • 43

2 Answers2

2

In my experience I found that it's better to use separate branches for things which have separate development cycles.

If you are going to release them always together as a single package and they are developed as a single product - single main branch is more appropriate.

If every application may be released in different moments, main branch per application seems to be more appropriate.

maxim1000
  • 6,297
  • 1
  • 23
  • 19
2

I like developing all the code in a single main branch. Then use a configuration setting to essentially disable the module for production and enable it for testing until it is ready for release. The added benefit is the modules (dlls) are already packaged for the release since you release early and often.

JimB
  • 31
  • 2