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.
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 am implementing a gitflow workflow with master and development branches, and I have 3 environments: DEV, UAT, PROD.
Using Azure DevOps, when the PR completes and the feature branch is merged into development, I trigger the release to DEV environment.
I am unsure on how to deploy to UAT after that. My first approach was to automate the deployment to UAT after the deployment to DEV succeeded (sequentially, DEV and then UAT), but it doesn't feel right to automate the deployment to UAT.
Should I create another branch for UAT deployments, and automate the deployment to UAT when development merges into that branch?
It's not need to have a branch for each environment. You should promote the artifact, not the source code. A specific branch should be integrated with the CI process, and its artifact should be promoted through each stage until production. The Continuous Delivery pipeline should reflect the environment stages, not the branch model.
A useful blog for your reference:
https://medium.com/#grazibonizi/understading-the-connection-between-branching-models-and-delivery-pipeline-c9cb12e30516
Heroku and Gitlab have Preview Apps as part of their CI/CD pipeline. Which is great for trunk based development as you get to test the branch in an isolated environment before merging the PR to master. Is there a way to do this in Azure DevOps? Could you use a custom Agent for this? How would you do that?
Our stack has React (client), .NET Core (api), MS SQL Server (storage). What I would like to add to our CI/CD pipeline is Preview App which can be used as QA step and we could also run our E2E Cypress tests against it.
Currently our devs have to run E2E tests locally as part of our PR process. For QA step we have to merge the PR to the master so that it will get deployed to our development server. Since QA works against our master branch we are forced to use release branches. After QA approves the merged PR, it's then cherry-picked to release branch. Release branches are then build and deployed automatically.
I would like to add QA step to our PR process so that we could deploy straight from master. Now we get it done, but I would like to streamline the process even more.
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.