Have you ever wanted to have a build that kicks off a bunch of other builds. I recently had such a need, we wanted to have independent build definitions for a bunch of apps. However when you are responsible for deployment you just want to run a bunch of builds at once. If every app is a .net application it’s easy to create one build that builds all the apps.
However in this instance we have two different build process’s. One for .net apps and one for VB6 COM applications. So we created a master build that can kick off multiple build definitions each having a different build process.
First thing is to strip down the Default build Process to it’s bare minimum. Here is what the Build Process looks like.
If you are familiar with the default build process you will recognize the first few items.
The ForEach is the new part. I will explain that in a minute. First we need a new Argument to the build process that will hold the build definitions you want to queue.
Name – BuildDefinitions
Direction – In
Type – String[ ] (Array of Strings)
and a new Variable for the output.
Name – BuildRetVal
Type – IQueuedBuild
Scope– RunOnAgent
You will need to get the Community TFS Build Extensions from Codeplex. If you don’t know how to get started using these, there is plenty of help on that subject here.
To Queue up a bunch of builds drag in a ForEach and iterate over the BuildDefinitions parameter you added.
Inside the ForEach drop in a QueueBuild from the community TFS Build Extensions.
Here is how you fill in the paramaters of the QueueBuild Activity.
Build Controller - BuildDetail.BuildController
BuildDefinition - BuildDetail.BuildServer.GetBuildDefinition(BuildDetail.TeamProject, item)
BuildServer - BuildDetail.BuildServer
Priority - Microsoft.TeamFoundation.Build.Client.QueuePriority.Normal
Process Parameters - Microsoft.TeamFoundation.Build.Workflow.WorkflowHelpers.SerializeProcessParameters(New Dictionary(Of String, Object) From {{"AgentSettings", AgentSettings}, {"Verbosity", Verbosity}})
Result - BuildRetVal
In my example I pass the Agent settings and verbosity through to the called definition. That way I can control them from the master build. In our case we wanted each child build to run on the same agent as the master build so we can accomplish that by passing in the AgentSettings to override those defined in the build definition.
We also passed in the Drop Location and used it in the child so that the child builds each dropped their binaries under the master builds drop folder. Again a choice we made for our situation.
Once you have the process we can define a build definition for the master build. Add all the Build Definition Names you want and the Master build will kick them all off for you. It should look like this.
