Todd Installs TFS - 00 - Why?

As I travel about, talking to you good people about software engineering practices and how to realize your development methodologies through Team System,  I often find occasion to demonstrate the product.

My demonstration environment is volatile -- I could be showing someone how to create 1,000 branches programatically one day, setting up a CI build the next and building and deploying a Silverlight demo on the third.  If I simply let these changes build up in my demo TFS installation, things could get pretty messy very quickly.  So, I observe a best practice.  I run TFS in a virtual PC with undo disks, and when I'm done meeting with a customer, I shut down the VPC and discard the changes.  It's as if the meeting never happened (as far as TFS is concerned, at least).

Corporate makes available to us several different VPC images -- ones with just TFS, one with TFS and all of the client Visual Studio tools, ones with hands-on labs, ones with TFS pre-populated with data (great for showing off TFS reporting), etc.  For piracy reasons, these images tend to be built upon trial operating systems -- i.e. copies of Windows Server 2003 with expiration dates.

Most of us out in the field tend to create our own VPCs.  We do so for a lot of reasons.  The #1 reason is that no one can stand the expiring VPCs.  It's not a fun experience to head out on an extended road trip, only to find 2 days into it that your VPC isn't going to be able to run any more because the trial version of Windows on which it was built just expired.  (Next imagine having this happen, but the new VPC with the new expiration date isn't available yet...)

Even if there was always a new VPC image available, we like to tailor our VPCs.  We are all individuals and have our own presentation styles.  As such, we each set up our VPCs to suite our presentations.  It's a real pain to switch to a new VPC, because you'll then spend a lot of time reconfiguring the new VPC.  If part of your personal configuration includes storing demo data within TFS, then switching VPCs becomes more of a nightmare.

Lately I've been 'cheating', using a great VPC image created by David Baliles and James Chittenden.  These guys are also the masterminds behind SDLC-in-a-Box, a fantastic resource if you want to do some self-study on using TFS for SDLC.  Their VPC is set up well, but it's not meeting some of my longer-term goals.  And, therefore, I'm yet again going to create for myself a new VPC.

I look upon this as an educational exercise; I haven't done a TFS install in nearly a year (although I have installed TFS many, many times).  This will actually be my first chance to do a clean install of the released version of TFS 2008.  So that's a good thing.  I also want to give Windows Server 2008 a spin, and now that the RTM build is available, this will be the real deal.  Lastly, I'm debating about whether or not to use SQL 2008 as my base repository.  It's not RTM yet, so there is potentially some danger here.

I've also decided that I do not want to run the client tools in a VPC.  I simply do not like the experience of running VS2008 from a VPC.  VS2008 'feels' great when run natively within Vista (my host OS); I'm not going to give that up.  One advantage of using VPCs is that it's easy to move to new environments (say, a new laptop or even just rebuilding your existing laptop).  But reinstalling VS2008 is not a big deal, so I'm okay living with this added risk.

I have not yet made a decision about how I'll handle automated Team Builds.  The easiest answer is to use my host Vista as the build server; that way, I can keep my TFS installation 'clean'.  I can easily change this decision later, so I think this is the route I'll take.

So, where does this leave us?  Well, it looks like the plan will be this:

1. Dell Latitude D820 running 32-bit Vista / 4GB RAM.
1. Visual Studio Team Suite 2008
2. TFS Power Tools 2008
3. Visual Studio SDK
4. Team Build
5. Virtual PC 2007
2. Virtual PC image running Windows Server 2008 Standard / 1.5GB.
1. TFS 2008
2. Windows SharePoint Services 3.0
3. SQL Server 2008 (really?)
4. Analysis and Reporting Services
5. Team System Web Access

Okay, there is one last thing.  I really want my TFS repository to be full of useful data -- so I can show off all of those great reports and charts.  But populating TFS with demo data is, well, hard.  You want the data to reflect reality (in terms of dates, etc.), so, in a sense, the only way to get 30 daily builds into TFS is to actually perform 30 daily builds.  And that takes (you guess it) 30 days (unless you start messing with the system clock and doing unsafe things like that).

I don't want to do this.

But someone has.  There is a corporate VPC image out there with a TFS installation chock full of meaningful data.  So I want to pull TFS from that image and put it onto my image.  But how?  Why, this is the same as doing a machine-to-machine TFS migration!  Fantastic -- another opportunity to learn something (I last did a full server-to-server migration 2 years ago, and obviously with TFS 2005).

So the plan is roughly taking shape like this:

1. Install client tools into Vista.  (An easy first step, as I already did this several weeks ago).
2. Create new VPC image.
3. Install Windows Server 2008 into VPC.
4. Install TFS 2008 into VPC.
5. Migrate TFS from 'reporting' VPC to my new VPC.
6. Configure Team Build in Vista.

(Talk about uneven task decomposition!)

I'll be taking this journey in this blog, so, if you are interested, keep reading.  All of the related posts will begin "Todd Installs TFS", so they'll be easy to find (or ignore).