Azure-devops-docs: How to configure a stage to require explicit execution?

[AArnott]

The docs imply that the default behavior is that a stage will run when its dependency stages have run. But how can we define a stage that requires explicit execution (like a classic Release's environment that I could deploy to manually)?
Ideally, I'd like a stage that requires manual deployment but may also express dependencies on other stages as well.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 4266f72c-c774-0046-4593-d01eb775d3c3
• Version Independent ID: f20827aa-a6c5-96a8-5969-e576ffbc2e38
• Content: Stages in Azure Pipelines - Azure Pipelines
• Content Source: docs/pipelines/process/stages.md
• Product: devops
• Technology: devops-cicd
• GitHub Login: @vijayma
• Microsoft Alias: vijayma

[noelbundick]

Same! Per the intro: "They are a logical boundary in your pipeline at which you can pause the pipeline and perform various checks." But it's not clear how to configure this pause behavior for stages

I want to configure my pipeline to:

• Build on every commit to master
• Immediately deploy to my dev environment
• Pause for explicit execution/approval before promoting to Test/Prod

[AArnott]

So what I heard from the product team is that this "approval per stage" policy isn't available yet but is on their backlog.

[Garrett-Smith-iq]

Is there something we can watch to get updates on this backlog item?

[theEyeD]

@Garrett-Smith-iq There is this: https://dev.azure.com/mseng/AzureDevOpsRoadmap/_workitems/edit/1510336/, but I'm not sure how frequently that will get updated

[katlimruiz]

For me this is a showstopper to adopt fully yaml pipelines. I do think UI pipelines are horrible but seems to be stuck with them for now.

[vijayma]

We will have approvals available as part of the multi-stage pipelines preview within the next 3-4 weeks. We update the roadmap work items once every quarter. You can also track the announcement of approvals feature in our release notes: https://docs.microsoft.com/en-us/azure/devops/release-notes/. Since, there are enough work items and places where you can track this, I am closing this issue. Thank you.

[pjcollins]

@vijayma are there any plans to extend on or modify the design constraints in the future?

Config-as-code poses interesting challenges for where you specify approvals. We plan to make infrstructure admins custodians for approvals, configure them as a check on the resource (agent pool, variable group, service connection, or secure file), and any stage that uses that resource will be paused for an approval.

I tried to test this out today and I can't configure a manual check on a resource that I personally created. It would be extremely useful for us to be able to have a stage (or stages) in our YAML pipeline that will only run when explicitly triggered by a team member. To take that one step further, it would be amazing to be able to approve such 'optional' stages with a /azp run foo GitHub comment. I would hope that don't have to go to an infrastructure admin to configure and/or approve gated steps on every PR?

If any future work to this end is still being considered, could you point me in that direction?

[vijayma]

@pjcollins The ability to configure approval checks on environment resources is just rolling out. (Other resource types will follow later). Your ask to be able to model a stage and kick it off independently is a little different, I agree. Why would you not want to do that as a standalone pipeline?

[AArnott]

Why would you not want to do that as a standalone pipeline?

Can a standalone pipeline (encoded in YAML) be associated with artifacts from a particular run of another pipeline (the way release pipelines do today)? If so, that seems reasonable to me.

[vijayma]

Yes, that makes sense. That is work in progress as well.

[AArnott]

... except that as of today, the "new pipelines UI" in azp doesn't show whether a build result has any release pipelines associated with it (the old UI showed this).
What is nice is when I can easily look at the build result I see which releases and environments have been kicked off from this build result.

BTW, it's particularly important that the build result UI update without a refresh. So many things on the build result page dynamically update as the build progresses, but at the conclusion of a build, any release pipelines with triggers on the build automatically get created but (even in the old UI) this isn't visible on the build result page without a refresh. Since some of my pipelines have triggered releases and others don't, I often forget and create a new release from the build result page only to find out that I've created a redundant release.

[pjcollins]

Why would you not want to do that as a standalone pipeline?

I have most of the same thoughts that @AArnott has already touched on. Artifact association, as well as some sort of breadcrumb / Web UI association would be the primary reasons not to use a separate pipeline for this today. It would be preferable not to have to have to "hack" around artifact transference between pipelines. It would also be nice to not have to remember to look at multiple pages/pipelines and instead have everything in one 'master' YAML file + templates.

[sonic1981]

I'd say the solution for this (https://dev.azure.com/mseng/AzureDevOpsRoadmap/_workitems/edit/1510336/) is far too inflexible. It also causes problems when migrating from a "traditional" pipeline to yaml. At the moment most of our release pipelines use a GUI but we are migrating to YAML. So this functionality is available in the GUI but not the YAML (or it works totally differently)

[AArnott]

@vijayma this issue was closed as resolved but the resolution is unacceptable. Environments are not an adequate substitute for UI-based release stages. These release stages could represent anything and include tasks to publish artifacts to nuget.org, for example. But these new DevOps "Environments" only allow Kubernetes-related resources.

Please re-open!

[gustavosavio]

Hello! Please re-open this issue. I need the one solution similar to Jenkins approach.

A good ideia would could to be:
```steps:

• script: 'something'
• input: 'Approve deployment to production?' (yes or no)
• script: 'something'
  ```

[jwikman]

@AArnott Environment works without Kubernetes. I've created several environments with manual approval without a resource. Just select "None" as resource when you are creating the environment.

That said, I still consider this a workaround. I would rather have something simple as in @gustavosavio comment. With that enabled I would just create a work item in the script right before the input, instructing someone to approve the next step in the pipeline.

But for now I can at least pause the pipeline execution until a user approves the next step.

[hintbw]

This particular request seems to line up with the following Azure DevOps Roadmap item for Q2 of 2020 - https://dev.azure.com/mseng/AzureDevOpsRoadmap/_workitems/edit/1663893 - credit to @bthuganator

[ovidiubuligan]

@jwikman I was in the same boat with the feeling that we need this in a simpler way, but after trying it it ofers quite some advantages over traditional way like jenkins. For example i you have 7 pipelines that all need to manually deploy when they reach production. When something breaks in production (or any environment ) you will now go to environments and look at the a chronological deployments for that environment . You don't need to check the dates that the production stage ran for all 7 pipelines . It is just a deployment label inside the yaml that makes all this auditing more friendly .

[AArnott]

I'm trying to adopt this now. But the docs are making it very difficult. I can't find a single example of the entire YAML structure from top of file to this approval-required environment including steps, etc. I'm left guessing how it fits, and I keep getting AzP rejecting my YAML for schema reasons.

[AArnott]

I've figured out the structure. But I'm still losing functionality by switching to YAML-based release pipelines.
With regular release pipelines, I got 'opt-in' deployment, but I also had auto-triggers where a tagged build could deploy automatically to the environment, and without the tag I could still deploy manually. I don't _think_ I can achieve that using environments with manual approval, as there's no way for the tag on the build to skip the approval being required.

[ovidiubuligan]

@AArnott is there a separate issue with the conditional manual approval missing possibility ? (I want to watch it)

[AArnott]

I haven't filed one. I wonder whether it's best to file it here in docs or (assuming it's a missing feature) if there's a better product repo to file it at.

[zejji]

Another vote for reopening this. The 'checks' feature attached to specific Environments doesn't work for us, as we have different stages of a pipeline deploying to different locations on the same environment. Some of these stages require approval (e.g. to the test location), but others do not (e.g. to the dev location).

This isn't currently possible using YAML pipelines and a single check attached to the Environment.