TeamBuild 2008

I was going to blog on TFS 2008 and TeamBuild 2008 together, but I figured I had better split it up to give the TeamBuild guys their due props!

We tried to use TeamBuild 2005 without much success as it didn't come with the expected Continuous Integration (not that it advertised it would, but the integration into any existing CI server was out of the question). Yes, we even tried the CI that was published in the MSDN article without success (it ran just fine, but wasn't useful for our resources or build configurations).

I went as far as writing a CruiseControl.Net plugin to try and use the TeamBuild TFS publishing capabilities (see previous post for more information).

When Micorsoft approached us asking us to join the TAP program they took particular interest in our CCNet setup and how TeamBuild 2008 would fare in a head to head comparison. We are now 3 weeks into that comparison and I have to say that TeamBuild is holding its own so far (and in some cases is the clear favorite).

Here is a quick run down of the comparison without trying to draw up charts, graphs, and tables:

• TeamBuild integration into TFS server and Visual Studio 2008 easily beat out the implementation for CCNet. This goes for the times when TFS is down for backup or other issues, you don't have to worry about a quiet period or period when the CI server shouldn't run.
• CCNet setup and ease of use beats TeamBuild, but not by much and it should be qualified with the fact that I have been setting up CruiseControl projects for almost 6 years now. With some documentation and help from the excellent folks at Raleigh I got the builds running as I wanted them to run, not just the default way that was shipped.
• CCNet dashboard and tray apps are more feature rich
• TeamBuild's CI options are more constrictive. You are only allowed a single trigger type and cannot combine them.
• TeamBuild's manual force of a build is more user friendly than CCNet has to offer and you can override properties being passed in (Huge!!).
• CCNet is a lot easier to customize to an organizations process.
• Extensibility would have to be a dead heat for me now. I have been able to create plug-ins for both CCNet and Team Build without much problem.

Not to take anything away from CruiseControl as I am a huge fan of the community and those who work hard to keep it at the head of the Continuous Integration movement, if a company is choosing to use Team Foundation Server as its source control, I would have to recommend they also use TeamBuild 2008.

For everybody else, CruiseControl is the hands down favorite and most usable CI platform on the net.

TFS 2008 Early adoption

I would like to a minute and record some of the effort (or lack thereof) of converting to TFS 2008 and TeamBuild (code named Orcas) from TFS 2005 no TeamBuild (Whidbey).

The guys at Microsoft have done an excellent job with this next release! Normally I am one of their biggest critics as they normally don't do things my way :). However, I have been a fan of the Team Foundation Server source control and project management suite since I was forced to migrate to it (instead of Subversion as I had planned). Understandably TFS 2005 had some growing problems as all new implementations are plagued with. I don't have to mention the installation as the first and foremost issue that most of us that had to administrate the system ran into. We ran into a few other issues, but for the most part TFS ran fine and the issues could be jotted down to our own growing pains.

So I would like to put my voice with the others who are blogging on how different TFS 2008 is than TFS 2005, and say that the setup is awesome! Well, at least a considerable jump from where it was originally. Hopefully the TAP program participants were able to sort out most of the more sinister setup issues, but it works like you would expect. Set the initial settings and click next and then come back a few hours later (depending on data size) and click Finish. Excellent!!!

We have been running 2008 server (with VS 2005 client) for a couple of months now with few interruptions. As an SCM, TFS is sure coming along nicely.

TeamBuild and CC.Net

I just finished coding a plugin that ties TeamBuild into the Continuous Integration (CI) environment of CruiseControl.Net. TeamBuild has been without a satisfactory CI implementation (although, that might change with Orcas), so out of love for continuous integration and a need to track builds in Team Foundation Server (TFS), I went to work.

The initial build was clunky and, with my lack of knowledge of TeamBuild, didn't work very well. The second generation works much better. I have added a logger that will monitor the running build and pump build steps into TFS while the build is running (what you would expect, but man was it hard to get there:). With the new task and along with some editing of the workspace.xml file to help keep the workspace slim and trim, I've been able to convert a few of the myriads of builds to TeamBuild (I am working on the rest in the coming weeks).

One of the problems that I am still having is with the way the Visual Studio view handles hyperlinks to web sites versus file shares. I publish the log as a link to the CruiseControl.Net dashboard, but when activated, it pulls the page into Visual Studio as source (haven't figured out how to get around that one).

A second, which is more important (that's why I listed it second), is that I haven't yet figured out how to update the GlobalList so that the builds are available for reports (still working on it though).

The logger is currently only useful inside the TeamBuild plugin, but with a little tweaking can be made to report any msbuild build to TFS (not sure you want to clutter things like that or not, but one never knows).

I have offered the plugin to Martin Woodward and his TFS plug-in for CruiseControl.Net project, but in the event that it doesn't make it I am more than happy to share (of course with the express permission of my current company).