TFS Build Automation Part 1 - Introduction

I've been using Visual Studio Team Foundation for the past 6 months now. I've banged my head against the wall ( a lot actually ) but I'm finally getting to a point where I feel that I'm in charge of it instead of the other way around. One thing that I really like about TFS is the Team Build product. Team Build is an agent that you install on your build box. It gives you the ability to kick off builds remotely.

For example, I'm able to open up VS2005 Team Explorer and go to Team Builds. I'm then shown a list of known build types in which I can bring up all kinds of information about previous builds and/or kick off a new build. Once I tell TFS to initiate a build of a build type, it sends the job over to Team Build and the process runs from there. All of this occurs without me needing to logon to the actual build machine. I don't know about you, but I think this rocks.

So what is a team build type? In TFS Source Control there is a special root level project called TeamBuildTypes. Each sub project represents a build type. TFS Build Types are pretty much solution centric. It's MSBuild based so really you could do whatever you want, but if you want to conform to the pattern think solutions.

The TeamBuildType consists of three files:

TFSBuild.proj -- An MSBuild project file that contains the built-in logic to use TFS to build a .NET solution.

TFSBuild.rsp -- a response file used to pass properties to MSBuild when firing up the build.

WorkspaceMappings.xml -- A simple XML file that maps your project area in TFS Source Control to your project directory on the build machine. This makes tasks such as keeping track of what changesets went into a build, labeling the files and getting them for compiling a piece of cake!

So after you install all the pieces of TFS and check a VS2005 .NET solution into source control, you can run the wizard and create your first TeamBuildType. With a couple more clicks you'll have TeamBuild building your first build.