Occasionally I'm asked about the business value of VSTS and TFS. I think it's pretty obvious, but I guess others need more convincing than just my word.

I've pulled together some links below that will help with this.

• Case studies - contains many ROI as well as technical case studies
• Customer evidence - contains some more case studies and testimonials
• Business value whitepaper - SDLC pain points and VSTS benefits
• Software lifecycles - a collection of scenarios providing evidence of VSTS benefits
• TFS Evidence Booklet - a PDF that was handed out at some of the roadshows

I was honored to learn that I had achieved the Bronze, Silver, and Gold awards for 2006.

Thanks to all of you who read my blog, attend my classes, and generally listen to me ramble on about Microsoft's tools and technology. Without you I wouldn't have these giant coins to carry around!

Join members of the Visual Studio Team System product group to discuss features available in Visual Studio Team Foundation Server, Team Editions for Architects, Developers, Database Pros, and Testers. In addition, discuss what's new in the latest Community Technology Preview (CTP).

Join the chat on Wednesday, February 7th, 2007 from 10:00am - 11:00am Pacific Time.

As many of you may know, Dr. Jim Gray (Microsoft Researcher and Turing award recipient) went missing a week ago, on his sailboat Tenacious off the coast of San Francisco. I've had the pleasure, on several occasions, of speaking with Jim and learning more about his research. If we cannot find him, it will be a huge loss.

The search for Tenacious (and Jim) is underway, in a big way. Many news agencies are calling it the largest private search for a missing person ever. This blog is aggregating all of the latest information. Best of all, YOU CAN HELP! Visit Amazon's Mechanical Turk site dedicated to finding Jim, and help by searching new/updated high resolution satellite imagery. All of the instructions are provided, you just need to donate some time.

Richard Waymire has publishes his long-anticipated whitepaper on permissions, security objects, and other security concerns centered around using the Database Professionals edition.

Over the years, we've had a few clients automate their build process by using Final Builder by VSoft Technologies. Much like Team (Foundation) Build, Final Builder is a powerful build & release management tool. Unlike Team Build, Final Builder has a slick UI allowing a build master to quickly design the builds.

Last summer, a new Final Builder version (4.2) was release which included more support for MSBuild and Team Build tasks. With that version, and following the guidance in this article, you can get the two products working together!

Wow!  As I was downloading a file from MSDN that requires Genuine Windows, I was prompted to download the required tool.  What was interesting was the prompt!  They noticed I was using Firefox and even showed me Firefox screenshots for how to install the Genuine Windows tool!

Bottom line up front:  Create a 'root' branch directly under the source control branch associated with a new Team Project.

I see this all the time...  Someone creates a new source control branch in TFS and starts creating solutions underneath the default project branch.  In other words, they end up with this:

$/ProjectName
    /SolutionName1
        /ProjectName1
        /ProjectName2
    /SolutionName2
        /ProjectName3
        /ProjectName4

Now, the difficult comes when the shop needs to create a second version of the application.  Code branches directly under the root (i.e., $/ProjectName) can only be created when a new Team Project is created.  If, in the above example, SolutionName1 and SolutionName2 both belong to the current version of the application, then creating a new version of the application will require either the creation of a new team project (with a branch from the $/ProjectName), or a wildly unweildly structure where each solution is branched, resulting in something like:

$/ProjectName
    /SolutionName1
        /ProjectName1
        /ProjectName2
    /SolutionName2
        /ProjectName3
        /ProjectName4
    /SolutionName1_v2
        /ProjectName1
        /ProjectName2
    /SolutionName2_v2
        /ProjectName3
        /ProjectName4

A MUCH cleaner approach is so simple, yet requires a bit of forethought.  Immediately after creating the Team Project, simply go in an create a new directory called 'root' (or 'edge' or whatever you'd like).  You can then create a full branch of the V1 off the application by simply branching 'root'.  This allows This resulting in the following structure, even after creating a v2 of the project.

$/ProjectName
    /root                           <-- Create this branch!
        /SolutionName1
            /ProjectName1
            /ProjectName2
        /SolutionName2
            /ProjectName3
            /ProjectName4
    /ProjectName_v2      <-- This is the branch of 'root'
        /SolutionName1
            /ProjectName1
            /ProjectName2
        /SolutionName2
            /ProjectName3
            /ProjectName4

Now, whether you should have your projects under your solution directories...  that's for another post...