Build Controller vs Build Agent

This is a great walkthrough that explains how to deploy a Database from a TFS 2010 Build WorkFlow.

It uses a command line tool called VSDBCMD.EXE, that is explained here.

I recently used this technique and it works great.

I actually created a pretty sophisticated build and deploy process using the build process templates from TFS 2010 to build a Database project and allow the user to decide via variables if they want to deploy to a Database or just create the script.

Something to watch out for though.

Take a look at the section titled “To define the Then Deploy block”

Then look at Step 3.d

Set the FileName property to the path of VSDBCMD.EXE on your build server. For example, you might specify C:\Program Files\Microsoft Visual Studio 10.0\VSTSDB\Deploy\VSDBCMD.EXE if you installed Visual Studio on your build computer or C:\Deploy\VSDBCMD.EXE if you just copied the Deploy folder to your build computer.

Notice the reference to “your build server”. This seems innocent enough of a statement. However if your Build controller is a different machine than your build agent it makes a difference as to where you can put your Invoke process to call VSDBCMD.

If you installed VSDBCMD on the build agent make sure the Invoke VSDBCMD is within the Run on Agent block in your Build process or it won’t work. If you follow the walkthrough and put your Invoke Process after the Check In Gated Changes block the process will not be able to find VSDBCMD.EXE because it’s installed on the Build Agent and at this point you are on the controller. If they are the same machine it won’t make a difference.

referring to the diagram below: If your controller and agent are different machines, everything in the Run On Agent block runs on the Agent and everything else runs on the Controller.