0

We have a development branch that is fed from feature branches through pull requests. After merge a build occurs and the artifact created triggers the release pipeline with some deployments happening automatically and others happening after manual approval.

After the approval happens for production, and after successful deployment, we would like to merge the PR that was was merge to develop to our main branch. I was wondering if this could be achieved automatically from the pipeline.

Note that not all the PR are going to make its way to production and the latest may not be the one being deployed in production.

Matt
  • 3,658
  • 3
  • 14
  • 27
cristian
  • 1
  • 1
  • If only a subset of the merges to develop will be merged to main, how would you handle merge conflicts on main if you are using an automated process? – Matt Feb 12 '22 at 18:41

1 Answers1

1

Assuming that you must complete the PR to trigger the CI build and release pipelines, you won't be able to re-use the existing PR to merge into another branch because PRs are specific to branches and once completed they can't be re-opened.

In theory, you could add logic to your release pipeline to create a new PR after successfully deploying into production but this is dangerous because PRs are based on branches and not individual commits. So if the develop branch changes while you're deploying into production the new PR would contain changes that haven't been deployed. If you have a small team and the number of PullRequests are low, this might not be a problem for you.

However, if you have a large team and dozens of pull-requests a day, you might benefit by adjusting your a gitflow branching strategy. In that model you would create a release branch and deploy that into other environments. Creating the pull request at the end of that pipeline flow makes total sense because you're deploying and merging a static branch.

For example, you could add a step in your release pipeline to create the PR using the Azure CLI:

$pr = az repos pr create `
         --source-branch develop `
         --target-branch main `
         --title 'merge $(Build.BuildId) into main' |
      ConvertFrom-Json
Write-Host 'Created PR $($pr.pullRequestId)'

There's another question where they're doing something similar.

Alternatively, look at the "Github flow" model. They use a trunk-based branching strategy where the PR is king and changes in the PR ultimately go to production or they don't get merged. The GitHub team had a model where they concentrated on a single PR at a time with a flow that looked like:

  • Designate a PR as a candidate for production
  • Automation would lock the target branch and create a temporary merge of the PR and the target branch
  • Automation would build this branch and deploy it to various environments.
  • Upon successful build into the environment, the automation would unlock the target branch and complete the PR.

It's worth pointing out that Azure DevOps does support triggering Releases from Pull Requests, and each PR-triggered build is a temporary merge of the target branch, so you could create a release and deploy it into your environments with your approval gates. You could add automation to your release to approve the PR:

az repos pr set-vote --id $pr.pullRequestId --vote approve
bryanbcook
  • 16,210
  • 2
  • 40
  • 69