Azure-pipelines-tasks: Make Azure Devops play nice with blue/green deployment

[johnknoop]

I have a release pipeline consisting of two stages: Staging and Production. I also have an Azure App Service with two deployment slots, also called "staging" and "production".

All changes to the develop branch gets deployed to the "staging" slot of my Azure App service.

When I promote the release to the Production stage, it just performs a slot swap. However, the Azure Devops UI doesn't track this swapping. Or rather, there's a discrepancy between the stages in Azure Devops and the slots in my Azure App Service.

If you look at this example:

When I promoted release 116 to production, release 115 automatically ends up in the staging slot (which is great if I need to do a quick rollback) but the DevOps UI indicates that release 116 is also currently deployed to the staging slot.

I understand that "stages" in the release pipeline isn't the same thing as deployment slots in an Azure App Service, and from a release pipeline perspective, release 116 _did_ pass the "staging" stage, so the UI is technically correct. However, it would be nice if the concept of blue/green deployment could somehow be incorporated, to support that workflow. Right now, if I need to rollback a release (perform a swap) I have to go into the Azure portal and do that. And once that is done, the DevOps UI no longer shows the current state of things, since no information is going from Azure App Services to Azure DevOps.

I don't have a concrete description of the kind of feature I'm requesting, but you probably get the gist of what I'm trying to say.

[RoopeshNair]

@johnknoop - yes, we are aware of this issue. We are planning to address this. As a first step, we are planning to introduce a first class notion of environments. As part of environments, we will enable tracking what is currently deployed and history of deployments from multiple pipelines on it. We also plan to make deployment strategies first class, so that we know what exactly is deployed to the targets and surface them on the environments. You can take a look at the initial specifications here. Please stay tuned.

Note, I'm closing this, please track the GitHub link shared above for the designs and support

[ArieHein]

hmm im probably missing something here.
When you create a web app with 2 slots, they are the same environment AND the same stage in the release definition. Swapping slots in the "Deploy Web App" task is done in one stage.

I think there is a mixup here between a stage (a logical UI that holds tasks), and environment (there can be many stages in one environment) and the implementation of slots (which also uses the term 'staging' to denote a state of the web app).

theres no UI changes that can be done to show blue/green in azure devops as that would cause you to duplicate stages and tasks just to show a UI change from say green to blue...

You do that by having an alternative monitoring / ops scripts that monitors your web app and detects swaps of slots and show it in the UI..but over all if the task of swapping slots in the pipeline was success, that's the sign for you that it moved from green to blue or other direction.

[bluszcz]

Any info regarding roadmap for it?

[RoopeshNair]

We are currently working on enabling canary deployments for Kubernetes resource (~2 months). We plan to support blue-green later.

[bluszcz]

Looking forward.

[emnak]

Hi @RoopeshNair, any update on this issue?

[RoopeshNair]

We shipped canary deployment strategy support for K8S resources. Support for VM resource and rolling strategy is in the process of rolling out. We would like to get feedback on these prior committing to other strategies such as blue-green etc. Currently blue-green is not on top of our backlog as we are working on the features that have broader impact

[ArieHein]

having it in K8S isnt really what the original creator was asking, for him its a web app.
I think my comment last year is still valid, i think slots are being used wrong.

Slots are not for dev being promoted into master.

Slots are for New prod replacing existing prod.
So in a release pipeline that consumes the build from the master branch.
you have a stage called prod, in it you have a task to deploy to web app, and you tell it to deploy to the staging slots, you can either add another agent job with a task to manage the web apps where you tell it to swap slots. and then the new master goes to the prod thus accessible via the normal URL and the "old" prod is moved to the staging slot.

you can place this functionality in one stage but break it in to 2 agent jobs, allowing you to place a agent less job in between where you ask for user approval, of you can create 2 stages (both are prod oriented), in one stage you have the deployment to Prod to the staging slot, and in the other stage you have just the swap of slots. This will allow you to use the builtin approval system.

Hope this gives a bit of clearance how to use slots

[johnknoop]

@RoopeshNair any idea if "environments" will eventually support Azure Webapp deployment slots as well?

[ArieHein]

environments is for VM Scale and K8s , why would you need that for slots when the actual deploy webapp task already supports slots ?
if you want to use WebApps for containers, then you dont need environments.

[johnknoop]

@ArieHein it's not the deployment that is lacking. That part works fine. The slots in our case represent different logical environments (staging, production etc), and we've set up corresponding environments in Azure Devops to represent the. So when we promote a release from staging to production, it carries out a slot swap. But then the problem arises: Azure Devops doesn't understand that the staging environment now runs the previous release. The same release can never run on both staging and production, yet if you look at the screenshot in my original post, that's exactly what it says is the case.