TFS Migration: Branching and Merging Strategy

As we are evaluating and planning our migration to Team Foundation Server 2010, considerations for adopting a Branching and Merging strategy for our source control projects has demanded a lot of our attention.

While using Visual Source Safe, our team rarely if ever used Branching to isolate project so they can be developed or supported in parallel with our main effort. VSS wasn’t so great at executing branching and merging, and we, like many, chose to err on the side of caution and forego branching altogether.

In TFS Source Control, it seems branching and merging have been improved to a level of comfort where we as a team can have some confidence that executing a branch or merge operation won’t lead us to spend more time cleaning up rather than moving on and doing the development work itself.

In the end, we have largely concluded to use branches to isolate our releases, but not to isolate our normal development during a sprint. As such, our Main (or Trunk) branch will be the primary (and consequently slightly unstable) code line. After each release, we will create a branch for that deployed version of the product for maintenance purposes.

Here are some of the key factors in our decision:

1. branches require a level or “care and feeding” that (for our relatively small team, at least) would have not yielded any great value for our normal development sprint. We rarely have divided teams working on the same product, or long running feature development in parallel to working our product backlog.
2. branching complicates IIS hosted applications. We choose to use IIS, rather than the Visual Studio Development Server, to host our applications during development. Consequently, every branch requires a reconfiguration of IIS to point to the site’s directory contained in that branch. While this reconfiguration be scripted (as demonstrated here) it still is another step that the developer has to remember to perform.
3. branching is further complicated when you have shared code libraries that must be replicated to every new branch. While there are some clever approaches to managing workspaces or using Build scripts to update branches, you can alleviate the whole issue by minimizing the branches you create.
4. we do not have a formal QA team that would require a stable Main branch for testing purposes. Our adoption of Agile is such that our peer reviews and testing are integrated in to our sprint, and consequently we are not ‘handing off’ our product to another team to exercise. If there were a QA team, then it certainly would be more important to keep a highly stable Main branch, and that would merit spawning a new Branch for ongoing development. In our case, it’s just not necessary.

It is nice to know that TFS Source Control makes branching and merging a more trustworthy operation, and that the tools are there when we need them. But for now, we’ll take the simple road.