Branching Guidance v2.0
I spend quite a lot of time with customers adopting Team Foundation Server discussing how they will branch, label, integrate, build and test their software. It’s actually one of my favourite topics, because I see good source control practices as the foundation upon which to introduce concepts that can revolutionise the software lifecycle and hence quality, in turn helping to reduce that all important Developer Discomfort Factor1.
The guidance on branching with TFS was revised in December 2008 – I’m running about a month behind right now due to the holiday season, hence the delay to this post! Anyway, be sure to check it out here. The new guidance includes some really clear documentation, labs, Q&A, and more.
One thing I particularly like is how the introduction encourages the reader to consider the cost of branching. When designing your branching strategy, always start simple… and when you can justify a new branch, add one. Don’t just adopt the most complex hotfix/service pack/kitchen sink approach.
Something that fascinates me about branching strategies is that you really must tailor the approach to your environment. This tends to mean two things;
· Use an approach that isn’t too far from how your developers work right now, so they can get used to the tooling without too much distraction from a different process.
· Use an approach that allows you to introduce more complex or alternative processes as you need them.
Reading through the Branching Guidance should help you get a good understanding of how this might be achieved. If you could do with more help, and you’re in the UK, get in touch with the UK ADC team.
1 Developer Discomfort Factor: A measure of the feeling of nagging discomfort a developer can experience on release day. This factor can be significantly reduced by introducing concepts such as automated tests to validate build quality thoroughly before release.