Create a Single Build/Release Pipeline for Multiple Branches

Posted on by mattruma

In this article we will look at how to create a single Azure DevOps Build Pipeline that triggers on multiple branches.

I am using the repository at https://dev.azure.com/maruma/SampleApp as the working example. If you would like to follow along you will want to clone this repository into your own Azure DevOps subscription.

This example depends on two branches, a develop and a master branch, and the work flow is as follows:

Whenever we commit to thedevelop branch, we want Azure DevOps to kick off a build and release to the Azure development environment.

If things look good in the development environment, we will create a pull request for the master branch, which in turn will kick off another build and release to the Azure staging environment.

If things look good in the production staging environment, we will then promote what is currently in the Azure staging environment to the Azure production environment.

Follow the steps below to create the Build Pipeline.

  1. In Azure DevOps, navigate to the project and then navigate to Builds.
  2. Click New and then New build pipeline.
  3. Click Use the classic editor, if you have YAML preview turned on, otherwise, skip this step.
  4. Select Azure Repos Git.
  5. If it is not already selected, select master branch, and click Continue.
  6. Select ASP.NET Core from the available build templates.
  7. Click Apply.

This repository contains multiple projects but we only want to build and release the SampleWebApp.

  1. Click Tasks.
  2. Click Pipeline.
  3. Add SampleWebApp/*.csproj for Project(s) to restore and build.
  4. Add SampleWebAppTests/*.csproj for Project(s) to test.

We now want to enable continuous integration to auto start our build on a commit.

  1. Click Triggers.
  2. Click enabled continuous integration.
  3. Add Branch filters for both the develop and master branch.
  4. Click Save & queue, and then click it again, select the develop branch and click Save & queue again.

This will create an initial build for our develop branch.

Now lets create our Release Pipeline based on the desired workflow.

  1. In your Azure DevOps project, navigate to Releases.
  2. Click New and then New release pipeline.
  3. Click Empty job, we will add the tasks later.
  4. Name your first stage to Development.
  5. Add two more stages, one for Staging and one for Production, again select Empty job and rename.
  6. Next to Artifacts, click Add, then select the build pipeline.

Now the fun begins.

We want to modify the Pre-deployment conditions for the Staging stage.

  1. Click on the lightning bolt icon on the Staging stage – should say Pre-deployment conditions if you hover over it.
  2. Change the Select Trigger to After Release.
  3. Enable Artifact filters.
  4. Click Add to create a filter for the master branch. This part of the release pipeline will only run for builds of the master branch.
  5. Repeat for the Development stage, except create a filter for the develop branch.

We now want to add an approval gate to the Production stage.

  1. Click Pre-deployment conditions, the lightning bolt icon next to the stage.
  2. Enable Pre-deployment approvals.
  3. Add yourself to the list of Approvers.

We are now going to enable continuous deployment, this will trigger the Release pipeline after a successful execution of the Build pipeline.

  1. In Artifacts, click the lightning bolt icon next to the build artifact.
  2. Enable continuous deployment.
  3. Add Build branch triggers for both the develop and master branches.

Last step is deploying to Azure.

This example assumes you have a resource group for each environment and a single web app in each resource group.

  1. Click the 1 job, 0 task link on the Development stage.
  2. Click Agent Job and click Add, the plus sign icon.
  3. Select Azure App Service Deploy.
  4. Select your Subscription.
  5. Select your App Service Name.
  6. Click Pipeline.
  7. Repeat for the Staging and Production stages, pointing to the correct Azure resources.
  8. Click Save.

Queue up a new Build for the develop branch.

When the build completes it should kick-off the Release.

To test the Staging to Production workflow queue up a new Build for the master branch.

Taking a closer look at the release triggered by the master branch build we can see the Artifact condition was not met for the Development stage, so it was bypassed.

You can also see that our Production stage is now pending Approval. Were you to click Approve it would deploy the Staging build to Production.

Hopefully this helped you and if not or if there was something I could have added/removed to make it more beneficial, please let me know.

God bless and keep coding!

23 Replies to “Create a Single Build/Release Pipeline for Multiple Branches”

  1. “If things look good in the production environment, we will then promote what is currently in the Azure staging environment to the Azure production environment.”

    I think that it should be: “If things look good in the staging environment”

    Reply

  4. Very good article, thank you! I do have a question regarding labeling or versioning of the release branch, how can that be included into the pipeline?

    Reply

  7. “If things look good in the development environment, we will create a pull request for the master branch, which in turn will kick off another build and release to the Azure staging environment.”

    I don’t see this anywhere in your article. From what I can tell, your process simply builds code that was committed to the dev branch and then you have gates pipelines that require approval to push the artifact to the respective environments, not the code itself. Am I missing something?

    Reply

    1. I am sure there is a way, just haven’t done it. Doing more with YAML as of late, so will take a look.

      Reply

      1. Is it possible to build and push images to two separate container registries using a single build pipeline? For example if I commit to develop branch it should build and push the image to develop-container-registry and if I commit on master the image should be pushed to production-registry?

        Reply

        1. While I have not done this, I would think it would be possible.

          My only recommendation might be, and granted, I don’t have all the context, rather than commit to develop and master and deploy to the container registry, would be to instead promote the build from develop and push that to the product-registry.

          Where I can, I like to keep the same bits and just promote through my various stages.

          Reply

  10. Hi Matt,

    Can you advise how we can setup the same build process you have outlined above but on a protected master branch? When I try to create a build pipeline I get the following error:

    TF402455: Pushes to this branch are not permitted; you must use a pull request to update this branch.

    Reply

    1. I managed to get my build process running by first creating a build pipeline since I could not commit my Azure DevOps yaml build configuration file to master branch once it was protected.

      Reply

  13. Hi Matt, Have you tried deploying to two different environment using prefix of branch. I have a situation when master deploy on Dev and then we create Release branch ( different names every time, like Release/1.0.0, Release/1.0.1, Release/2.0.0). How can i tackle this?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *