0
votes

I'm trying to configure Azure DevOps Release pipelines for our projects, and I have a pretty clear picture of what I want to achieve, but I'm only getting almost all the way there.

Here's what I'd like:

  1. The build pipeline for each respective project outputs, as artifacts, all the things needed to deploy that version into any environment.
  2. The release pipeline automatically deploys to the first environment ("dev" in our case) on each successful build, including PR builds.
  3. For each successive environment, the release must have been deployed successfully to all previous environments. In other words, in order to deploy to the second environment ("st") it must have been deployed to the first one ("dev"), and in order to deploy to the third ("at") it must have been successfully deployed to all previous (both "dev" and "st"), etc.
  4. All environments can have specific requirements on from what branches deployable artifacts must have been built; e.g. only artifacts built from master can be deployed to "at" and "prod".
  5. Each successive deploy to any environment after the first one is triggered manually, by someone on a list of approvers. The list of approvers differs between environments.

The only way I've found to sort-of get all of the above working at the same time, is to automatically trigger the next environment after a successful deployment, and add a pre-deployment gate with a manual approval step. This works, except the manual approval doesn't trigger the deployment per se, but rather let an already triggered deployment start executing. This means that any release that's not approved for lifting into the next environment, is left hanging until manually dismissed.

I can avoid that by having a manual trigger instead of automatic, but then I can't enforce the flow from one environment to the next (it's e.g. possible to deploy to "prod" without waiting for successful deployments to the previous stages).

Is there any way to configure Azure DevOps Release Pipelines to do all of the things I've outlined above at once?

2
Would it help to change the pre-deployment manual approvement gate to the post-deployment one? I guess this could shift the logic a bit and instead of making the next stage hanging doing nothing you "hang" the current one.Andrey Stukalin

2 Answers

0
votes

I think you are correct, you can only achieve that by setting automatic releases after successful release with approval gates. I dont see any other options with currect Azure DevOps capabilities.

Manual with approval gates doesnt check previous environments were successfully deployed to, unfortunately.

0
votes

I hope this provides some clarity after the fact. Have you looked at YAML Pipelines In this you can specify the conditions on each stage

The stages can then have approvals on them as well.