We have a continuous delivery pipeline which has a pre-approval step for the prod deployment. Many of the releases will only be deployed to lower environments before we pick a final release to move to production. Despite disabling notifications, ADO is still sending out emails to approve prod deployment every time a release moves through all stages.
Is there a way to shut these off? I don't want an approver inadvertently clicking on approve in an email and sending the release off to prod.
This is how the release notifications are configured in the project -- both manual intervention and approval pending are disabled:
Related
I have an azure pipeline that triggers on a branch commit to build the content of the branch and automatically create a release.
I tried to add the Pre-Deployement Approvals in the release stage conditions, and this sends a notification in slack channel where i can approve the releases.
This workflow works just fine. Today i wanted to experiment with jira and azure devops, so i intalled the integration Azure pipeline jira integration to keep track of the releases that belong to a specific ticket. This is the extensione i am using:
https://github.com/Microsoft/azure-pipelines-jira
This works well and i can see all the releases in the ticket issue. But i was wondering if there is any way to enable the approval on a release and when this trigger to send a notification in jira to be approved instead of slack.
Thank you so much for anyone who can point me on the right direction if any.
My requirement is to promote the same artifacts from UAT to Production.
My release to UAT is manual, whereas my release to Production is triggered when UAT completes.
The release to UAT and Production have approvers. My issue is that, after release to UAT completes, the approver automatically gets an email to approve release to Production. This confuses the approver, because testing in UAT takes a few days and I don't want to send them an email for Production immediately.
So my question is - is there is a way to promote the very same artifacts in UAT to Production with a manual trigger for Production?
I solved this issue by adding a post-deployment approval to the UAT environment, as a signal that UAT tests passed properly.
Context
We have a C# project, hosted in Azure devops.
We have a pretty standard workflow :
build + unit tests,
manual QA,
then mark the built artifacts as "validated by QA".
These artifacts are then made available to our deployment team.
Since our product is deployed on our clients' premises, the actual deployment will not be triggered from the azure pipeline.
Situation
So far, we work with a build job, and we communicate with the deployment team by sending a notification : "build 345 is validated, use that one for deployment".
The problem is : they basically have access to the list of all builds, including the ones which were built correctly, but where QA found a bug for example.
What I would like to have
Give the deployment team access to a section where only validated builds are published.
This could be :
using a release pipeline : let the result of the release pipeline be to offer the artifacts for download
but I did't find an action which just states "publish the artifacts"
in the build pipeline, keep the builds in a "not yet completed" state, and wait for a manual action of the QA team to flag them as "success" or "failure".
I don't see a way to add a manual step to a "Build" job (and I think this would be a bad setup for a build job anyway)
Question
What would be the prefered way to represent this workflow in azure devops ?
Then you could have a release pipeline with only these tasks:
1. Manual intervention Sends an e-mail to the QA-team telling them to do their thing with build x.y.z. When the build is approved for release, someone from the QA-team signs into Azure Devops and lets the release resume.
2. Notification E-mail or whatever notification you're using goes out to the deployment team, informing them about the newly approved build.
I have the following release pipeline set up in Azure Dev Ops for web deployments:
Release Pipeline - Web Deployment
How this is configured...
Continuous Deployment is enabled
The Development stage is triggered after release, has no pre-deployment approval and will deploy the artifact to the dev slot.
The Test and staging stages are triggered after the previous stage, have pre-deployment and post deployment approvals enabled and will deploy the artifact to the relevant slot.
The Production stage are triggered after the previous stage, has only pre-deployment enabled and will swap the staging slot with the production slot.
The rollback stage is manually triggered, has only pre-deployment approvals enabled and will swap the staging slot with the production slot.
I understand that when an approval for a stage is still pending, another release can't be deployed to that stage. For example R1 is waiting post deployment approval on the test stage, therefore no subsequent releases (R2, R3, etc.) can queue the pre-deployment on the test stage. I'm also aware on the Deployment queue settings functionality but don't think this helps here - happy to be wrong.
So my question is...
Is there an automated way to stop a subsequent release overwriting the staging slot before we have approved the production stage, which swaps staging to production, for the current release?
and my example is...
Post deployment on the staging slot for Release 1 (R1) has been approved. This means 1) that the pre-deployment on the production stage (swap staging to production) can be approved for R1 and 2) the staging slot on R1 is "free" to be deployed to from another Release. So now, R2 could have pre-deployment for the staging stage approved, meaning it will deploy R2 to staging potentially before we swap staging to production for R1. As such, if we approve R1 to production, we will swap R2 into production, not R1 as intended. Still with me! Also, we don't want R2 being deployed to staging until we have possibly approved the production stage, so that if we need to rollback (swap production to staging) we are swapping in the original version, not R2.
I hope that makes sense. Obviously this could be managed manually to avoid this scenario but hopefully someone might be able to advise how this might be achievable automatically.
FYI - first Stack Overflow post, so go easy on me if I've not follow protocol ;) and thanks in advance for any help.
I have a release definition set up in VSTS which releases from UAT through to Production.
The release is automatically created after a successful green build and the trigger to UAT is manual. I have the production trigger set up off the back of the UAT deployment with a manual approval step.
What I can't figure is - how do I stop the release being able to be deployed to Production if it has failed to deploy to UAT?
The scenario I have had today is - deployment to UAT failed due to some failing tests but the approvers can then approve the release to Production. I want to stop this to reduce risk of broken functionality going out to a Production environment.
Use the Abandon option. Once a release is abandoned it won't progress.