Azure-devops-docs: How to just do manual propagation instead of approvals?

[fmms]

Hi,

with classic pipelines one could easily just manually deploy to different environments. We have used that intensively and after testing a build on the TEST environment. We deployed exactly that build to the PROD environment.

How can I achieve this with YAML multi-stage pipelines?

As I understand the documentation Approvals are a sophisticated solution to this. However, I do not really need this additional level of possibilities, I do not want to specify names and require these persons to propagate a release to and environment. As stated in the documentation currently ALL users have to approve, it is not possible to define that ANY OF the users can approve thus it is really unusable for the above use case.

How can manual propagation be done without any approvals? It should be the easier option instead of an approval procedure. However, I cannot find this anywhere in the docs.

Please help.

regards
Felix

---

Document Details

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

• ID: b067a175-f640-7503-9c1e-f0130c6dbeda
• Version Independent ID: ff743c7b-a103-eae6-4478-62ba995a4b36
• Content: Pipeline deployment approvals - Azure Pipelines
• Content Source: docs/pipelines/process/approvals.md
• Product: devops
• Technology: devops-cicd
• GitHub Login: @shashankbansal
• Microsoft Alias: shashban

[shashban]

We currently do not have an ability to manually start stages in yaml pipelines.
@vijayma to comment

[mweinand]

We are looking for this too. We want the deploy process in code, but each stage/environment as a manual event that someone clicks "Go" on.

[mkajerski]

You can set a whole group (e.g. the team) as approver, that way anyone can promote a release to the next stage.

[gradyal]

Is there any sort of workaround to not being able to setup manual deployments? I have this currently setup using the classic release pipeline UI such that in-sprint work gets manually deployed to a test environment so as not to burden our QA with approval emails. I'd prefer to have a similar setup using multi-stage pipelines.

[derekrprice]

@gradyal Not sure what you mean. I followed the docs and set up automated build on merge, followed by a second stage with automated deployment to a test environment, followed by a third stage with automated deployment to a production environment. If you add approvals to the environment definition, then they will be required. Otherwise, deployment just happens automatically.

Strictly speaking, I used "show yaml" in a classic environment to get the code rather than coding all the yaml from scratch, but everything worked mostly like I expected and wanted.

[gradyal]

@derekrprice I also fully read and understand the documentation. With the classic release workflow, there is a concept of pre-deployment condition with a manual trigger. This means deployments are triggered for a particular stage manually. That manual deployment concept is not currently available with multi-stage pipelines. Approvals are ok if you want everything merged to be required for approval. In my case, in-sprint merges create builds which each create releases that accumulate and I don’t want QA to have to approve things that aren’t ready to test. I’d rather those deployments be triggered manually.

[PaulVipond]

@gradyal I have a similar requirement. I've already got a build pipeline which packages up every available component artifact into a single artifact for release. Looks like I'm going to have to have a second deployment pipeline which is run manually and deploys to test and production. Test and production would then have approval requirements, key thing being if you don't run the deployment pipeline manually (specifying the release version) then you don't have to approve that version into any of the environments.

[sesispla]

I also find the current approval mechanism very limited and less flexible than classic release pipelines: We are using Azure DevOps Classic Release to deploy Terraform infrastructure and heavily relying on them for:

1. Check Terraform execution plans
2. Approve the roll-out of infrastructure changes to new environments (each stage is an environment).

I started an open-source Azure DevOps pipeline implementation for Terraform but is useless unless I get manual interventions back...

@vijayma I see you commented on this task when completed. Do you know if any further work will be performed around YAML pipeline validations?

[jderose9]

I have the same use case - automatic deployment to a staging environment, and manual deployment to production. Manual approvals essentially does what I want, but the user interface is very bad. The build time keeps ticking upward and then the pipeline ends with a time out result if a particular build is never pushed to production. The previous/classic Release pipeline supported this use case without concern.

[gradyal]

@shashban Is the ability to manually deploy currently in development? Is there a roadmap item tracking this that you can share?

[janlunddk]

Now that the "Stages To Run" dropdown has been added, it helps somehow as a workaround for manually triggering deployment stages.

However, all stages are selected/enabled by default, which makes it kind of dangerous if someone runs a multistage pipeline without deselecting the stages that must not be run in a manual trigger scenario, e.g. in a Terraform scenario where each stage represent an environment (as outlined by @sesispla above).

It would be great if we could control the check-state of the "Stages To Run" checkboxes using e.g. an Enabled: true/false property in the YAML for each stage.
This will make it possible to make it mandatory to select the stages you want to run in the "Stages To Run" dropdown. And in this case, it would probably be better to have a visible checkbox-list instead of a dropdown.

If this feature is already available, please document how to make the stages in "Stages To Run" start in a deselected state, from YAML.

[austincrft]

I also need the ability to deploy manually to environments. Setting approvers is insufficient because not every build will go to production. This means most builds would be considered failed due to a timeout, which defeats the entire purpose of the "pipeline failure" metric.

It would be better if there was no timeout and stages waiting on approval did not increase the pipeline time

[Sjark]

We have also solved this issue by using approvals, but it should be possible to at least configure deployments to be set to "Skipped" not "Failed" when timeout expires, cause most of our builds now fail for this reason.

[austincrft]

Because there as been no response from Microsoft here, I have submitted the following: https://developercommunity.visualstudio.com/content/problem/913044/allow-manual-releases-in-yaml-release-pipelines.html

[nerijusk]

Because there as been no response from Microsoft here, I have submitted the following: https://developercommunity.visualstudio.com/content/problem/913044/allow-manual-releases-in-yaml-release-pipelines.html

Yours might be the duplicate to https://developercommunity.visualstudio.com/idea/697467/manually-triggered-stages-in-yaml-multi-stage-pipe.html, which has already been raised on Aug 16, 2019.

[Barsonax]

Has there been any progress on this? Still noticing the wrong status being reported (waiting or even failed because of timeout...)

[sesispla]

In terms of my previous comment, we've been deeply investigating how environments and deployment works and looks like is possible to have the "manual intervention" behaviour in YAML pipelines.

It took a while to understand how it works, as all the puzzle pieces are documented separately, so the problem is the documentation, not the lack of functionality.

The process would be:

1. Create an environment
2. Add manual approval to your environment
3. Create a YAML pipeline as usual
4. Create a deployment job
5. Include the environment name you created in "1." to the deployment "environment" property

When you do this, Azure DevOps will automatically wait in any task that tries to deploy to this environment. You can even add more deployment gates, which is really nice!!

And on regards of the multi-stage approval, the workaround we applied here is for each environment to depend on the "Build" stage, giving us the ability to trigger more than one deployment at the same time.

It is true we are missing the ability to trigger a stage manually. But at the same time, it makes little sense, as, for instance, we have dependencies between stages.

Not easy to solve, but at least this workaround with "dependsOn" give us what we needed.

[PaulVipond]

Back to the point made by @austincrft above. It would be good to view this by environment, looking at the builds which are waiting to be approved into an environment, rather than searching for the pipeline build that made the deploy which you want to now release. I also echo his concerns about timeout.

[Sjark]

Yeah, we use the approval gate based on environment, and that works fine. Our problem is that let's say we have set a automatic reject after 72 hours, the job will go in error status if not approved within 72 hours. I would like it to just set the jobs it couldn't do due to not being approved as skipped, so the Deployment as a whole would be successful, not failed.

I'm not sure that should be the default, but it should at least be a configurable option.

[michaellihs]

Can anybody tell me, whether an "open approval" blocks the build agent for the time being? I mean if a pipeline runs into the step where an approval is required from a user, is the build agent blocked until the approval is granted / rejected?

[Sjark]

@michaellihs Yes, when you get to a Stage that is blocked due to an approval, it will wait there for a configurable timeout. If you approve within that timeout, the build will continue, if not it will fail.

[Krusen]

@michaellihs As far as I know it doesn't block the build agent. When approved it will then be queued and wait for an available build agent to continue.

[janlunddk]

@michaellihs, Maybe it was a typo, but this issue is at the stage level, not step level.

The pipeline will be blocked, not the agent itself, as the stage does not start before it is approved. This means that your agent can be used from other pipelines in the meantime.

[PaulVipond]

Just to be clear, can you submit a new run for the same pipeline while a previous run is awaiting approval?

[Sjark]

@PaulVipond Yeah, you can have several jobs running at the same time. They will all run like normal until the Approval stage.

For instance, if you have a build stage that does not need approval, then a deploy to Production that do need approval, the build stage will run, and wait at the production stage.

If you then start a new pipeline job, it will also run the build stage, then wait at production stage for approval.

[derekrprice]

@michaellihs, @PaulVipond, @Sjark, that's not quite true. We encountered this. In Batch CI mode, the pipeline with the pending approval will not allow other Batch CI mode builds to start (maybe only for the same branch). PR builds for the same pipeline start just fine, as do builds in other pipelines.

I believe you can turn off Batch mode, if you don't mind race conditions. We just reduced the approval timeout to 24 hours so that pipelines don't stay blocked for long, and we get an email about the problem. It's the FIRST notification that we get due to a bug with environment based approval notifications.

[marchom]

I understand the environment approvals and that adds a lot of flexibility to our setup.

The issue that I have is the failure metric as well as the total runtime for a pipeline.

When we are using a dashboard for visualising the state of our pipelines we get a huge bias for 30 day long runs (configured timeout) and number of failures for builds that did not make it all the way to PROD. This defeats the entire purpose of having a dashboard for our pipelines which otherwise would give us an overview of metrics like- are we increasing/decreasing our time-to-prod, are we failing during specific env deployment, etc.

I would love to at least see the change that a skipped approval is set to cancelled instead of failed.

A bonus would be the ability to exclude cancelled builds from the Pipeline History widget in the Dashboard.

Perhaps this in general is a separate issue and if so let me know and I'll create it separately.

[cxwtool]

This issue hasn't been updated in more than 180 days, so we've closed it. If you feel the issue is still relevant and needs fixed, please reopen it and we'll take another look. We appreciate your feedback and apologize for any inconvenience.