TFS Build Architecture

Question

I am preparing to move my team's source control from VSS over to TFS 2008.

This is for an asp.net website, and I am currently using a combination of nant scripts and Cruise Control to do all of the builds and deployments.

I've been trying to wrap my head around the best way to architect TFS build to do the same thing I'm doing with NANT and Cruise Control, but I can't determine the best approach.

Here are my requirements:

1. When code reaches a certain point, I manually apply a label to it.
2. This labeled code needs to be built and deployed to any of our 25 different Dev, QA, or production environments.
3. Any of these 25 environments can be on any current or past labeled version of the application.
4. I need to be able to deploy any labeled version of the application to any of the environments.

I'm currently accomplishing the above using NANT to perform the build, and using Cruise Control to just pass in command line options for which environment(s) to build and deploy. I have a Nant config file with a list of all of my environments, and an associated label each environment should currently be using. This file gets manually updated whenever a new label is created.

I know the approach I'm using for NANT probably won't be the same as with Team Build, but has anyone done something similar with Team Build and could share how you accomplished it?

Answer 1

1. Labeling in TFS is much more robust than in VSS. When you create a label, you can create based on a changeset, date, workspace version, heck even a different label. (BTW, I was grabbing a link and came across this post that you might find relevant.)

2. By default, a Team Build will build from the latest version of code in source, but you can override the "CoreGet" target in a build to build a specific version. Aaron Hallberg (a.k.a. TFS's John Skeet) shows an example here.

3. see 4.

4. I haven't personally had this difficult of a requirement, but I've done something similar. When you queue the build, you can pass in any number of parameters in a couple important ways, 1) through the response file and 2) at queue time (simple example here). In either case, two parameters could be which environment and which label/version number. At my current project, I have continuous integration turned on, so when code in a workspace is checked in, the current code is automatically labeled, pull the specifics for my drop location from the response file, then deploy to the respective location.

Given the fact that you have ~25 environments and n number of versions/labels, you could build a simple GUI that reads the current labels through the TFS API and lets you pick which version to build to a particular environment.

Answer 2

To answer the question, the way I addressed this was to use a combination of a custom build task, cruise control, and msbuild.

The custom build task allowed me to get the latest version from a specific branch and label.

Cruise control allowed me to pass in specific information for a specific build to MSbuild, using a config file, but initiate the build from a UI.

msbuild was used like normal, however it was called from cruise control, and the custom build task did most of the work.