3
votes

I'm attempting to configure a release pipeline in Azure DevOps (on premises) to support a git-flow strategy. What I'm trying to achieve:

  1. Commits to 'release/*' trigger a build of the software and publish to a location for QA
  2. Commits to 'master' take the same software build (artifact) from step 1 and publish to Production location

So when I do a git-flow 'start release' the software is made available for testing/QA and when I 'finish release' it's made available to users.

My build pipeline works fine, it's triggered by the release branch and concludes with a Publish Artifact task. My release pipeline uses this artifact and has stages for QA and Production but the Production stage never triggers. For QA I've got an artifact filter for 'release/*' and on Production for 'master'.

Is there a way to trigger my second release pipeline stage on a commit to 'master'?

2

2 Answers

3
votes

As a general flow this won't work unfortunately. When you commit to release branch your building from release branch. When you commit to master branch you will have to build again for an artifact to be oriented from a master commit.

You'll either need to be happy with:

  • 1 x build from commit to release OR master and release to both environments
  • 2 separate builds for release to separate environments
2
votes

For your issue, if you want to automatically trigger a deployment to different stages based on commits to different branches in a Build Artifact source, this is not feasible.

Agree with Bevan , if you only want to use a build artifact as source for release pipeline, you can set Pre-deployment approvals for QA and Production stages. When you want the build artifact from the release branch to be deployed to the QA stage, you can approve the deployment on the QA stage. When you want the build artifact from the master branch to be deployed to the Production stage, you can approve the deployment on the Production stage.

enter image description here

You can also create two build pipelines, one for the master branch and one for the release branch. Then create separate release pipelines for the two different build artifacts. One is used to deploy to QA stage and the other is used to deploy to Production stage.