One of the big things we’re working on in Team System land right now is getting ready to update to the latest version of Team System for our internal use…we’re currently doing business on top of VSTS Beta2. As others (such as RickLa and JohnLawr) have noted, we use a lot of VSTS in the development of VSTS.  This is one of my most favorite aspects of my job…using our own tools, for better or for worse, to build our tools. It really helps us stay close to our customers, experience the pain and joy of using our tools and as things go well, increase our confidence that we’re building the right product with the right level of quality for a team of our size and complexity. 

Much to my chagrin, we don’t use all of VSTS broadly within the VSTS team.  But for each dogfood refresh (which we undertake every 3 months or so) we try to expand both the feature coverage as well as the scale of usage.  For this upcoming refresh, for instance, we expect to use a few more aspects of the system regularly:

   -   Source control from the IDE (today we use the command line interface)
   -   Hardcore reporting from the data warehouse
   -   Publishing test results
   -   Building all of Team Foundation with Team Build (today we only build Team Build with Team Build)
   -   Source control proxy server

As you can imagine, bringing a team of hundreds onto new toolset that’s still under development is no small challenge.  We’ve been actively planning the migration for the past 4w and still have 2+ weeks before we go live. The migration of data is clearly one big challenge since the schemas and organization of the data has changed since Beta2.  We develop scripts to migrate this data and as you can imagine, testing these is a big job unto itself.  We conduct a series of dry runs (the first of three planned dry runs is currently underway) which basically involve migrating the data and then conducting a series of bug bashes to ensure that the data moved correctly and that we can use the new toolset as productively as before.  We’ll have folks specifically focused on ‘bashing’ the new areas above to ensure that they’re ready to go live. 

To help us stabilize and service this toolset, we branch our source tree, creating a new “dogfood refresh” build.  This helps us isolate ourselves from the continued churn as we fix bugs and provides us a way to patch our tools when we find a dogfood blocking issue.  This of course means that if we find a blocking bug after the branch, we have to fix it in two places so it’s a bit more expensive.  But it’s worth having a separate branch so that we always know that we can build a fix right away.  We’re on the verge right now of making that branch and so we’re pushing hard to get the last known dogfood bugs and work items closed down (we use Team Foundation work items classified with a sub-iteration path to track these) before we branch and stabilize. 

It’s an exciting time.  I’m really eager to taste this new dogfood.  Yum yum!

jeff