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 the
develop 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.
- In Azure DevOps, navigate to the project and then navigate to Builds.
- Click New and then New build pipeline.
- Click Use the classic editor, if you have YAML preview turned on, otherwise, skip this step.
- Select Azure Repos Git.
- If it is not already selected, select master branch, and click Continue.
- Select ASP.NET Core from the available build templates.
- Click Apply.
This repository contains multiple projects but we only want to build and release the SampleWebApp.
- Click Tasks.
- Click Pipeline.
SampleWebApp/*.csprojfor Project(s) to restore and build.
SampleWebAppTests/*.csprojfor Project(s) to test.
We now want to enable continuous integration to auto start our build on a commit.
- Click Triggers.
- Click enabled continuous integration.
- Add Branch filters for both the develop and master branch.
- Click Save & queue, and then click it again, select the
developbranch and click Save & queue again.
This will create an initial build for our
Now lets create our Release Pipeline based on the desired workflow.
- In your Azure DevOps project, navigate to Releases.
- Click New and then New release pipeline.
- Click Empty job, we will add the tasks later.
- Name your first stage to Development.
- Add two more stages, one for Staging and one for Production, again select Empty job and rename.
- 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.
- Click on the lightning bolt icon on the Staging stage – should say Pre-deployment conditions if you hover over it.
- Change the Select Trigger to After Release.
- Enable Artifact filters.
- Click Add to create a filter for the
masterbranch. This part of the release pipeline will only run for builds of the
- Repeat for the Development stage, except create a filter for the
We now want to add an approval gate to the Production stage.
- Click Pre-deployment conditions, the lightning bolt icon next to the stage.
- Enable Pre-deployment approvals.
- 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.
- In Artifacts, click the lightning bolt icon next to the build artifact.
- Enable continuous deployment.
- Add Build branch triggers for both the
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.
- Click the 1 job, 0 task link on the Development stage.
- Click Agent Job and click Add, the plus sign icon.
- Select Azure App Service Deploy.
- Select your Subscription.
- Select your App Service Name.
- Click Pipeline.
- Repeat for the Staging and Production stages, pointing to the correct Azure resources.
- Click Save.
Queue up a new Build for the
When the build completes it should kick-off the Release.
To test the Staging to Production workflow queue up a new Build for the
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!