With the flexibility in branching, it’s very easy to create a branch per feature. Sometimes I notice that people lack the same enthusiasm when it comes to creating build pipelines for these new branches. The downside of course is the more build definitions you create, the more administration overhead in keeping them all up to date as you make changes to your build pipeline. Wouldn’t it be great if you could just use one build definition to build all branches? In this blogpost I’ll walk you through a trick to use just one build definition to build all branches in your repository…

One build to rule them all!

For the purposes of this walkthrough let’s assume you have the following branches

  • master main line for production
  • develop integration for all features
  • feature/myfeature1 feature development branch

Let’s see first how you can set up one build definition to trigger for all of these branches…

  • Let’s start off by creating a new build, choose an empty process image.png
  • Call the build OneBuildForAllBranches and select a build pipeline, now navigate to the triggers section in the build and set the Trigger as Continuous Integration. Click the branch filter drop down and in the search box type * and press enter image.png

The build definition is now set up to trigger itself for changes in any branch in your repository. You could optionally reduce the filter scope by using specifying the branch filters to be excluded from the * all branch setup.

  • To test this is working, you can make changes in any of these branches and you’ll see the build executes just fine… image.png

O wait! That’s a problem, I want to now identify the build by the branch it was executed for, otherwise I might accidently deploy my feature branch into production directly…

How to reflect branch quality in build name?

  • In your build pipeline add a PowerShell task and copy the below shared code snippet…

if ($env:BUILD_SOURCEBRANCHNAME -eq "Develop"){
     Write-Output ("##vso[build.updatebuildnumber]" + $env:BUILD_BUILDNUMBER+"-beta")
      write-host "setting version as -beta"
      if ($env:BUILD_SOURCEBRANCHNAME -ne "master"){
           Write-Output ("##vso[build.updatebuildnumber]" + $env:BUILD_BUILDNUMBER+"-alpha")
           write-host "setting version as -alpha"
  • In the PowerShell script above, I am simply using the predefined variables and prefixing the name of the build beta or alpha depending on which branch the build is being created from. Now if you run the builds for all the branches you’ll see the quality reflected in it’s name… image.png

Ok cool! Now you are probably thinking, how can I stop my alpha build from accidently rolling out into the production environment?

How to filter branchs in environments in release pipeline?

  • Start off by creating a release pipeline and link it to your build pipeline. Create three environments, for example DevTest, PreProd and Prod image.png

  • For the pre-prod environment, click on the Pre-deployment Condition icon and select Artifact filters. This setting would block the Feature\* branches from being released into the Pre-Prod environment. image.png

  • For the Prod environment, click on the Pre-deployment Condition icon and select Artifact filters. This setting would block all branches except master from being released into the Prod environment. image.png


In this blogpost we saw how easy it is customize the build name by using the name of the branch it was triggered from and then how to set up the release pipeline to filter out specific artifacts from being released into specific environments. Hope you found this useful…


About author
Tarun Arora
Tarun Arora
Tarun Arora is obsessed with high-quality working software, DevOps, Continuous Delivery and Agile. His core strengths are Azure, Azure DevOps, PowerShell, SQL and WPF. He is a Microsoft MVP in Visual Studio Development Tools and the author of 'DevOps & ALM with TFS 2015'.
We Are
  • onlyutkarsh
    Utkarsh Shigihalli
    Microsoft MVP, Technologist & DevOps Coach

  • arora_tarun
    Tarun Arora
    Microsoft MVP, Author & DevOps Coach at Avanade

Do you like our posts? Subscribe to our newsletter!
Our Book