Now on MSDN: patterns & practices Team Development with Visual Studio Team Foundation Server guide

You can now find our patterns & practices Team Development with Visual Studio Team Foundation Server guide on MSDN in HTML. It's the same guidance we hosted on CodePlex. CodePlex was our channel for agile release. Once we baked the guidance, we ported to MSDN. For some customers, MSDN is a trusted source, so being on MSDN is important. Additionally, MSDN provides some additional hooks and channels.

Download
You can still download the Team Development with Visual Studio Team Foundation Server Guide from CodePlex.

~Later

Team Development with TFS Guide - Beta 1 is Available

Wondering where I have been hiding all these days? Well for last couple of months I have been working with our patterns & practices team on Team Development with Team Foundation Server Guide. Today we released our Beta 1 for this guide. This is our guide to help show you how to make the most of Team Foundation Server. It's a distillation of many lessons learned. It's a collaborative effort among product team members, field, industry experts, MVPs, and customers.

Even though I have already contributed to articles on MSDN for Whidbey Security, but this is my first contribution towards a complete book and I am pretty excited about it. The main reason being its about Team Software Development which itself is an exciting topic.

If you are using Visual Studio Team System, I would urge you to read our guide and provide feedback to make it even better and be part of this exciting journey. You can download our beta 1 version of the guide from the following location:

http://www.codeplex.com/TFSGuide/Release/ProjectReleases.aspx?ReleaseId=4442

~Later

To Branch Or Not to Branch

The other day I was working on a guidance document for branching strategy in Team Foundation Server. When we looked at some of the customer references, we realized that a fantastic feature like branching is misused more than often. Talking to number of customers we realized some or the other time Configuration Managers and Developers come face to face with the dilemma, To Branch or not to branch?

The answer to this question is, you should not branch!! For many simple scenarios, you don't need to branch and labeling your builds is sufficient. Because with branching merging comes into the picture, the complexity of branching increases the pain of merging exponentially. Said that, you should branch only when you have to isolate parallel development efforts. Here are few common scenarios which gives insight as to when and how you should branch.

• If you are working on one release at a time, then you just don't need to branch, just work from your main trunk.
• If you want parallel development while you prepare for intermediate release and need to stabilize the release build, then you need to branch the release source code. Do testing / bug fixing on the release branch and parallel development on the main trunk. Once the release is done, you might / or might not want to merge the bug fixes to the main trunk.
• If you have to make a patch or hotfix on an old release with parallel development for a new release, then, you branch the old release. Do testing / bug fixing on the patch / hotfix release and parallel development on the main trunk. Once the patch or hotfix is done, you might or might not want to merge the bug fixes to the main trunk
• If you are having regular problems with broken builds, then a create development branch to isolate parallel development efforts. Merge the development regularly with the main trunk, which can be used for stabilized build.
• If you have features which can be worked in parallel, but might cause stability among each other, then branch the main trunk for each feature development. Merge the feature branches regularly into the main branch and reverse merge for features to share code. The main branch is used for stabilized build.

These are the very basic scenarios, and depending upon your team you can have combination of more than one scenarios. Thumb of rule to follow is avoid branching, and branch only when you have to do parallel development.

There is a good document - Explained: Branching in Team Foundation Server, which gives insight on the branching strategy.

So no more, To branch or not to branch dilemma.

~Later

Visual Studio Team System Guidance

There is lot of good product documentation available for Visual Studio Team System and Team Foundation Server, but very little contextual guidance. Whatever little guidance is available, its dispersed over the net. There is no single source of comprehensive trustworthy quality guidance, which is easy to consume.

I am really excited to share that, in an attempt to fill up this void, I have teamed up with J. D. Meier, Alex Mackman and Jason Taylor on Visual Studio Team System Guidance project. Being a small team, we are planning to go by "divide and rule" mantra. So we are focusing one area at a time.

Last week we focused on Source Control and came up with some good Practices, How Tos , Explained and Q&A. Additionally we are creating Video Based Guidance, which are short, focused videos for performning a task or learning a concept.

We have published these guidance on http://codeplex.com/VSTSGuidance/ . You are most welcome to provide feedback on these guidance and be part of an exciting journey!!

~Later