Visual Studio Team System 2010: Tick, tock, tick, tock...

simonince — Tue, 21 Apr 2009 15:34:00 GMT

As the beta 1 drop of Visual Studio Team System 2010 approaches, Brian Harry has a great little summary of the high level new feature areas we’re delivering. Check it out here.

There are some great nuggets in there, so I’m really looking forward to RTM – lab management, gated check-ins, and the architecture tooling are some of my favourites.

Branching Guidance v2.0

simonince — Tue, 13 Jan 2009 14:25:00 GMT

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 Factor¹.

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.

¹ 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.

Simon Ince's Blog : TFS

Visual Studio Team System 2010: Tick, tock, tick, tock...

Branching Guidance v2.0