Check out my new article on Coding4Fun. It describes a game I built for an internal coding challenge here at Clarity.
Here at Clarity, we hold infomal internal training events a couple times a month to discuss new technologies, tools, or other things related to software development. Recently, Don Peterson led a discussion on source control management strategies for development teams using Team Foundation Server. Some of what was discussed was based on Microsoft's Branching Guidance white paper. I've read the paper before and I think it is a good read, full of good info. The focus of our discussion the other day was Release Isolation since that is probably the most commonly used strategy. The paper shows branching for release isolation in this way:
I agree with the approach in spirit, but I think it's worthwhile to ask yourself a few questions to see if you need this much complexity:
-
How big is my team?
-
Do we need isolated feature changes?
-
How does development process work?
For small teams (< 10 developers), I think it can be in your best interest to simplify your branching structure to something more like this:
First, let's recognize that TFS, like any product, has some issues. As I've experienced lately, merging large structural refactoring changes can cause problems. I think you're best off limiting merges and merging often. And with smaller teams you don't necessarily have a lot of independent work going on and may not need separate Dev and Main branches. Main is meant to be your stabilization branch, but if your development team works together well in a single branch you can limit some of the merging needed by conceptually combining those branches. Feature separation is still possible by creating branches off of Main as needed. When it's time for QA, I think it's okay to simply branch off for the release and build your QA release out of the release branch (i.e. Release 1.0). Bugs found in QA testing can be fixed in the Release Branch and then merged back to Main. The final signed off QA build becomes the release version and then the release branch can have security locked down so that the only changes that will ever go into the release branch will be for approved hot fixes.
In summary, I'm not suggesting the approach described in the white paper is flawed. These are smart guys and everything makes sense. I simply think that it's best to be practical and consider what you really need to succeed.