In TFS 2005 we introduced the concept of Build Machine that ran the

build service and had the ability to compile and run team builds.

The build machine was hardcoded in the build script and couldn’t be

change unless modifying the script. A build request to busy machine

leaded to an error.

In TFS 2008 the concept was upgraded to Build Agent that manages

the connection between the build and build machine. As all the build definitions

in TFS 2008 it’s stored in the Database and it’s not hardcoded in the script.

The build agent knows to manage a queue of builds and a build request to a busy

machine enters the queue and waits for it’s turn. Another abilities are to change

the target agent when requesting a build (overriding it’s default agent), and

installing two agents on the same machine using this method.

In TFS 2010 we announced a new concept: Build Controller.

The Build Controller manages the Build Agents and knows to queue the

requested build to the most available agent. Installing new agent (on the same

machine or on another machine) became much easier. Everything is done from

the new Team Foundation Administration Console  :

(notice the new agent button).

Another change is that the build process is now separated to two parts the “controller scope”

and the “agent scope”. The “controller scope” is responsible for the build initialization

(name,drop location etc) and the “agent scope” is responsible for the compilation.

Q. What happens if I want to use a specific Agent because of some prerequisite installed

or preferred machine?

A very good question – but the answer is even better …

A. You can name and tag your Agents :

When you request a build you can choose your preferred Agent by name or by tag using

wildcards:

I think this is a real quantum leap to have a Build Farm with multiple build agents and

machines and managing it all is pretty easy through the Build Controller.

I’m really looking forward for the release….

Happy New Year !