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.
Related
I've got a Azure Devops project that's deploying to an app service that has a workflow that looks like this:
On PR creation, build gets triggered.
Build kicks off a CD pipeline to deploy app service to a staging slot
Stage 2 of the CD pipeline is swap staging and prod. This requires an approval
PR Still needs to get completed manually
The reason I wanted to build it this way was so that anyone pushing changes to the repo could validate them in the staging slot in the live environment before they went into prod. The flow seems to work, except that there are two things to do at the end of a change. The approver must approve the swap to prod task in the pipeline, and the associated PR must be completed. I've found cases where the PR never gets completed, which means that you end up with unmerged changes.
Is there a way that I can have the release pipeline (which is triggered off a PR build) complete the associated PR as part of a release stage? I'd like to make sure that what gets merged into the main branch is the current code, so I'd rather not change it to trigger on PR completion because at that point things are already merged, and a breaking change would have to be undone. The other way I figure I could handle it would be to:
On PR Creation, trigger a validation build, and a release pipeline to deploy to the dev slot.
On PR completion, trigger a release pipeline to deploy the PR build to prod.
This would change the approval flow a little, but might be better at making sure that the PR gets completed properly.
I actually ended up coming up with a different flow for this. What I got working was:
Create PR for feature branch
PR creates build
Staging release pipeline triggers off PR, and deploys to a staging slot
Changes can be validated in staging
PR completion merges to main branch
Merge to main triggers a CI build pipeline
CI build triggers a release pipeline that goes to the prod slot
This means that the PR must be completed in order to release to prod. It does mean that the build that goes into prod isn't necessarily the same one that's in staging, but it's built from the same code, so that should be identical.
I have configured a release pipeline in my environment in a way as dev -> test -> uat -> prod stages.
My query is whether its possible to disable the manual deployment happens to individual stages like we should not be able to deploy to uat until the test stage is completed.
Right now we will be able to manually run the uat stage even if the dev and test stage is not completed or we haven't run those stages.
Currently we cannot disable manual trigger for particular stage in release pipeline, but we can control deployments using approvals, so you can set a pre-deployment approval for uat stage, and then deny broken deployment. Also we can set Gate for stage, see: Release gates and approvals overview for details.
I'd like to set up a pre-deployment gate with the following logic
If the branch (embedded in the artifact names, i.e. 1.2.4-myBranch)
matches the currently deployed branch (to the stage in question) allow the release to deploy automatically
If it doesn't match, require a manual override before the release is
deployed
The reason for this is we have multiple test environments where generally we only want to allow a release from the same branch to overwrite the deployment but obviously once we're done with a particular phase of testing we'd want to change the deployed branch.
I can't see any obvious way to do this, is it possible?
As a workaround:
We could create two Stages A and B
Select the stage A and configure the pre-deployment as below:
And configure stage B trigger mode to Manual only
Result:
If the branch match master, it will allow the release stage A to deploy automatically.
If not, we need to manually deploy stage B
You could also add your request for this feature on our UserVoice site, which is our main forum for product suggestions. Thank you for helping us build a better Azure DevOps.
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.
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.