Team Foundation Server 2010 For Developers part 2 - Advanced Source Control

by Dmitry Kirsanov 4. December 2011 19:03

This is my second post about Microsoft Visual Studio 2010 Team Foundation Server for Software Developers. The previous one is here.

Now that you know how to submit your code to the source control, associate work items and use that information in your daily work, it’s time to learn the rest two things we skipped in the first part. The Branching and the Shelving.

Team Foundation Server is an Agile-oriented platform, and therefore many of it’s concepts supports the existing models of Agile Software Development. One of such models is Source Code Promotion Model, which basically means that your code moves through 3 stages – development, testing and production.

A word of warning: each model of Agile is a double bladed sword. It expects you to meet the conditions which will make this model effective, and if you fail to comply – you’ll get ineffective implementation, which could ruin your software development efforts. In case of Promotion Model, make sure you have a dedicated team of testers – not just developers from other project who came to rescue, but professional testers who are not doing any development. If you don’t have dedicated testers – forget about Promotion Model.

So, in case of Agile Code Promotion Model, you have 3 code trees, or branches – one for “unstable” Development branch, one for Quality Assurance (Testers) - still unstable by definition, as when it get’s stable, it is “promoted” to Release branch.

Other scenario when you could use branches – when for some weird reason you have to have two or more versions of your application separated in different code bases. Just for your information, different versions of Windows, Visual Studio, Microsoft Office and other software products do not have different code bases – you get the same binaries each time, and “edition” is decided upon settings and serial number. Once released, the code base is not modified, so there is no need for branching in that case.
However, if someone paid you a million to get “his own” version of product and you couldn’t make it via modules, add-ons or whatever – perhaps you should create a new branch.
Anyway, the YAGNI principle of Agile should be applied when you are considering to implement the Promotion Model. And YAGNI stands for You Ain’t Gonna Need It.

So, when you have branches, you can separate the different versions of the same code base and allow different teams of people to work with them. Or keep the branch for read only reference. However, one benefit is provided by Team Foundation Server when you are using branches - the merging of changes, which allows to propagate changes you make in one branch to all other branches, when needed.

Another thing, which you could use time after time, is Shelving. It basically means that you can save your changes into what is called “Shelveset”, to restore these changes later. For example – you checked out the code, made your changes, they are not finished yet so you don’t check in, but suddenly you have to make urgent changes to existing code base. You have to get the latest code base without your recent changes and perform other changes, requested by the latest task. That’s when you need shelvesets. You shelve your changes, revert project to the latest sources from the Team Foundation Server source control, perform changes requested by urgent task, check in changes to TFS, and then unshelve your changes so you can continue with what you were doing before getting the urgent task.

Here is the video I’ve created to illustrate the topic. In this lab you will see what branching and shelving are about and how to use them in Visual Studio 2010. Hope you’ll learn something new!

Team Foundation Server for Software Developers part 2–Advanced Source Control
blog comments powered by Disqus

Month List