BuildMaster is an application release automation tool. In this tutorial, we will demonstrate how to select a specific build in Visual Studio Online, and pull a release package from that build.
Previously we ran through how to kick off a new build in TFS / VSO and then import that build into BuildMaster. This is the way most of our users integrate TFS, or any CI engine with BuildMaster, however there is another feature that some users take advantage of.
In this tutorial, we’ll set up a new pipeline for the application we’re pulling from TFS so that we can pick a specific past build to import.
You can download the sample Otterscript plan and JSON files used in this tutorial.
BuildMaster allows, and encourages, users to create multiple pipelines for their applications to cover a host of release scenarios. We’ll name this pipeline Import Specific Build, as well as give it a color to clearly identify it as a non-standard pipeline.
This new pipeline will mirror the standard pipeline stages of Import, Integration, Testing, and Production from the previous tutorial.
We’ll next set an application variable and use that variable in a Release Template, which will allow us to pick a specific build definition, and build number.
First, we’ll set the application level variable. This variable will set $TfsProject to the specific Project in TFS we’re working with. In this case, Accounts. You set application variables under the settings tab.
We’ll then create our release template, name it, and set it to the new pipeline.
First, we’ll add a Release Variable to pick which build definition we want. We’ll name it TfsBuildDefinition, and make sure that the value is required and limited to items in list. We’ll choose Dynamic List (TFS Build Definition), and set our credential and use the application variable ($TfsProject) as its type.
Next, we’ll add a Package Variable to our template that will allow us to pick a specific build number. Again, the value will be required and restricted to list items. We’ll name this variable TfsBuildNumber and it will also be a Dynamic list (TFS Build Number). Again, we’ll set our credentials, use $TfsProject, and this time we’ll use the variable we just set for the build definition ($TfsBuildDefinition).
Also, we’ll make sure that the value is required, and also limited to items in the list.
We now have a release template that, when used, will prompt us for a build definition and a specific build number. Next, we’ll use these variables in a new deployment plan.
Even if we’re using a previously defined deployment plan to move the application through the new pipeline, we still need to import the build, and we need a new plan for that. We’ll name the plan Import Previous Build.
This new plan will start with a General block and short description, and then add two operations, Import Artifact from TFS, and Set Release Package Number. The first operation will let us select a build to import using our variables.
The second will let us set the package number. We’ll use the $TfsBuildNumber variable so that the package number is the same as the build number.
Please note that if you choose to set the package number to the same number as the build in TFS you may also need to change the Package Number Scheme to Date-based (which can be found under advanced settings) in certain situations. This allows for a package name to be reused in the same release.
We will then save and assign this new plan to the Import stage of our pipeline, and select the stage to automatically promote to the next stage of the pipeline, Integration.
Now that the new pipeline, plan, and template are in order we can create a new release using them.
We’ll create a new release, and set the template and pipeline to Import Specific Build. We’ll also have a drop-down to choose our Build Definition, in this case Standard.
When we create our package another prompt will appear for the Build Number.
Once set, BuildMaster will then import the build number specified and the release package can be moved through the rest of the pipeline.