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.
Related
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'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:
The build pipeline for each respective project outputs, as artifacts, all the things needed to deploy that version into any environment.
The release pipeline automatically deploys to the first environment ("dev" in our case) on each successful build, including PR builds.
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.
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".
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?
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.
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.
We are using trunk based development and we have dev sandbox and production environments in Azure DevOps. We move build from dev to sandbox to production by promoting the builds. After moving build to production if there is an issue is there anything the pipeline i can define to trigger a rollback.
The only other option I can think of is get the last know commit number and trigger a build with that commit number. and let the pipeline take care of the rest. Is this correct is there a better way to do rollback in AzureDevops
Each release is a snapshot of the deployed artifact(s) and variables. The simplest "rollback" is simply to go to the Release Management history for the project, locate the previous release, and deploy it again to replace the newer release. Complications can arise if there are, for example, incompatible database changes.
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.