Sogeti Phoenix Blogs

I've recently taken to learning about Microsoft's Team Foundation Server. It has a good API and I wanted to see if I could do something similar to what I did with SubVersion and Python. So, I spent the weekend getting everything up and running.

For comparison's sake, here is how you install and create SubVersion repositories in a commonly used development environment:

• Download SubVersion.
• Install it.
• Don't like the command line? Download TortoiseSVN and install it.
• Right click somewhere and select "Create repository here..."

Four steps (with two being optional). The biggest problem I had with the TFS install was that it took far too many hoops to jump through that I almost considered giving up. Fortunately, I'm stubborn and pushed through.

Firstly, TFS can install on a domain-less network (like what I run at home), but I figured that the most common implementation is on a domain, so I created a new VM and installed Windows Server 2008 for the Domain Controller.

[It should be noted that this isn't necessarily a good differentiation from the SubVersion install, since the best practice would be to install SubVersion on a separate server, preferably Linux based.]

Once the Domain Controller was set up, I installed SQL Server 2008 since that is what TFS uses as the data store. This too went without a hitch.

However, upon starting the installer for TFS I was greeted with a message stating that it cannot be installed on a Domain Controller, or a server running "Enterprise" applications (Exchange, BizTalk, etc).

I'm assuming this is for security reasons, which brings me to a grumbling point I have with TFS: there is no "Developer Version." It must be installed as if for a production environment. I understand that Microsoft wants to ensure that their customers aren't doing something stupid and opening themselves up to attacks, but this is solely on a virtual environment that will be inaccessible from the outside. SQL Server has a developer version that can be installed on a client OS, why doesn't TFS? And further, you can install SQL Server and IIS on a Domain Controller, which is already a bad practice, why not TFS?

Anyways, after some mild cursing I spun up another Virtual Machine for another Server 2008 installation. Fortunately I have 4 Gigabytes of RAM in my workstation, though at this point I was wondering if I should convince my wife that upgrading to a quad core processor would be worth it.

Eventually, the second server was up and connected to the domain. Installed SQL Server 2008 again and went to install TFS. This time I got an incredibly worthless error message that annoyed me enough that I Twittered about it. It effectively said that there  was an error, but it was so dire that it couldn't be displayed in a dialog, so you should check the logs, but there wasn't even a link to where those were. I briefly looked in the filesystem, but didn't see anything obvious. Hindsight says that I should have checked the Event Viewer, but I hate digging through that and I found my solution regardless.

I suspected I had missed a pre-req and consulted the documentation again. Herein my second grumbling point. The documentation for TFS is a .chm file. I hate these things. They're essentially hypertext viewers, but without any benefits from modern browsers, like tabs. I would have loved to have opened a bunch of different tabs for each page I was looking at, but was stuck with a Single Document Interface.

The missing pre-requisite was IIS. Whoops, my bad. Installed that lickety split and fired up the installer. Again, I understand that the target market for TFS is larger development groups with 10,000+ users, and a powerful web server is required for that, but for tiny groups, why not just include Cassini or something similar?

This time I did not get the stupid error, but failed when it scanned for the required pre-requisites (somehow IIS was needed to get to this part). There were a few errors regarding my SQL Server install, it needed Analysis Services, Reporting Services, and a couple of other things. Whoops again. It also said that my version of SQL Server was incompatible, though at the time I figured that this was the catch-all error to display when there were other problems too.

Went back to the SQL Server 2008 installer and added everything except the Management Studio and on-line books. See my similar bone of contention with needing IIS for enterprisey development, when something tiny and embedded would be awesome for me.

Again, my version of SQL Server was incompatible. More cursing, though a little stronger this time, because I knew that SQL Server 2008 would work with TFS 2008. After sifting through the documentation some more, I found that SQL Server 2008 will work with TFS 2008 Service Pack 1. Of course, there wasn't a download available for an installer with both, so I had to merge the service pack into the base installer (I would love to link to a webpage detailing this, but again, .chm file).

Finally, I was able to install TFS 2008. TFS also requires SharePoint (why?), but one good thing about the 2008 version is that it will install SharePoint Services 3.0 automatically for you. This is good because if you think this post is just a rant in disguise, it's cupcakes compared to SharePoint. My memory may be faulty but I believe that TFS 2005 did not do this for you, so 2008 gets high marks here.

This is starting to seem like a Shaggy Dog story, but that was basically it. My install wasn't exactly a standard one; I should probably keep SQL Server and TFS on separate machines, but I only have so much memory for these resource intensive virtual environments.

The moral here is that this install experience borders on unacceptable. Yes there were some user errors, but those could all have been taken care of in a Developer Version. SubVersion only features Source Code Management, but in my experience most developers only use TFS for that as well (which is sad since it offers much more). Installation is the very first thing that people see when they actually use your app, and it will color their opinion throughout the rest of the experience.

Installing TFS requires the developer to dig through mediocre documentation. Developers hate reading documentation, when things should "just work." And installers need to be simpler, especially when they don't always have to be Enterprise level.

Team Foundation Server (TFS) has a great feature called shelving. It allows you store a copy of your source code changes on the TFS server. Please note that this is different from checking in the code, because the copy is set aside temporarily or shelved under your userid. Since the code is not checked in you can be confident it is not going to break your team's nightly or continuous build.

There are several ways to shelve your changes. The easiest way to do it is from Visual Studio, click on your Pending Changes window, and select the files and click Shelf button. In the dialog window that opens up enter a Shelveset Name and click Shelve. If you give a Shelveset Name that is already existing it will ask for confirmation to overwrite it.

For unshelving, open Pending changes window in Visual Studio and click Unshelve. By default it will show you all the shelvesets for your userid. Click on the self set name from the list and click Unshelve. It will bring down your shelved code files to your local workspace automatically check it out from the TFS server.

For more ways including command line to do shelving and unshelving look at the MSDN documentation here.

Some of the uses of Shelf feature are:

• Set aside temporarily a feature or some code change that you are working, because you are now assigned a different task or a bug to fix.
• Collaboration on a code change. Say you are working on a code change and you need some extra information from another team member to finish it. You can shelf your code and have your team member unshelf it and provide the extra information and check it in.
• Use it for code review purposes before checking it in for build.
• Use it as a personal code change backup. I normally give a shelfset name of bkp (because I am lazy), and allow the confirmation dialog to overwrite my existing backup. You still have to remember to manually do this though. I have made it a practice to do this before I leave for the day. May be I will automate this some day and blog about it.

For more information about shelving and unshelving look at MSDN documentation here. There is also a 10 min video here that gives you a hands on approach.