CODEWITHSUNDEEP
azure-devops
Mikee
Mikee

Reputation: 1651

What is a Team Services Release Definition 'Post-deployment approver'?

It makes sense to have a pre deployment approval for an environment but what is a post deployment approval and why might I use it? No definition in Team Service docs here

Upvotes: 3

Views: 1309

Answers (2)

Daniel Mann
Daniel Mann

Reputation: 59036

Different groups sometimes "own" different environments, so they control when things deploy to their environments and when things are ready to leave their environments. The scenario I commonly use to explain this is as follows:

You have a dev server that's owned by developers. Changes get pushed there and signed off on by a dev team lead. The dev team lead does a post-deployment approval for the "Dev" environment.

Then it goes off to the QA environment. The QA team might be in the middle of some manual testing of the previous build. They want to conclude that before the next build comes their way, so the QA team lead get a pre-deployment approval. The devs might sign off on 10 releases in the interim, but the QA team lead can choose just to take the most recent one, since testing older builds isn't doing anyone any good.

Then, the QA team signs off and it goes to a UAT environment. UAT is owned by the product owner, who frequently demos the upcoming changes to upper management and/or end-users. The product owner will want to control when a UAT deployment happens, because they don't want their demo to get ruined by an inopportune deployment. Without a post-deployment approval owned by the QA team, the product owner might take an untested, unvalidated build and deploy it and end up demoing something horribly broken, making everyone look bad.

And so on.

Upvotes: 4

James Reed
James Reed

Reputation: 14052

Validating testing is the main scenario I can think of. Imagine a deployment chain that goes

Dev -> Test -> UAT -> Prod

So I set up a trigger to deploy to dev on every check-in / commit and run some basic smoke tests.

Then I set up a scheduled deployment to Test for 3AM and run a more comprehensive set of automated tests, however certain bits of the application still rely on manual testing. The testers can approve or reject the release post deployment based on if they find any bugs. If the testers (or test lead) don't approve the post deployment step then the release cannot proceed to UAT.

You then might have Business Users who approve deployment to UAT and once testing is complete validate that the release can go live. (Another post deployment check)

Finally you might have a check that approves deployment to production.

If you have 100% automated testing in all environments then you don't need these kind of manual interventions, however if you still need manual testing then this can prove a fairly light weight way of ensuring a sensible approvals process is in place.

Upvotes: 7

Related Questions