Blue/Green deployment is a deployment model in which we keep two production-like environments on active-active standby. In this case, one of the environments is always serving production traffic while the other one can be idle or be used for testing features. So, what happens, in this case, is that one environment always contains the latest code which needs to be in production while the other environment contains the older production code.
Getting the latest changes in production is as simple as swapping the DNS to point to the environment containing the latest code. Rolling back a deployment which doesn’t meet the expectations is as simple as rolling back to the previous environment containing the older production code.
Let’s discuss how we can use Azure Web App Deployment Slots and Azure DevOps Tools like Repos, Pipelines (Build/Release) to automate this process.
Azure Boards provides backlogs and work item tracking to help development teams collaborate and coordinate their work.
Azure Repos fires a trigger to launch a Build Pipeline. The Build Pipeline includes jobs and tasks that clone the repo, install tools, build the solution, and then package and publish artifacts to Azure Artifacts.
Release Pipeline is responsible for deploying the application artifacts to development, QA, and production environments. The Release Pipeline is organized into stages which, although executed sequentially, act independently of each other. In this scenario, the Dev stage deploys the application to a Dev environment. This environment is typically hosted in a non-production Subscription and may share an App Service Plan with other non-production environments such as QA.
Between stages, you use approvals and gates to control when the next stage is executed. This allows your team to perform testing and validation in each stage before moving onto the next.
Blue-Green Deployment, the staging slot represents your “green” deployment. The production slot represents your “blue” deployment. Once you validate that everything has been successfully deployed to the staging slot (i.e. green), the Prod stage performs a swap of green and blue. This makes the green deployment live for end-users and moves the blue deployment to your staging slot where it remains until you remove it. If problems arise with the new green deployment then you can swap again to move blue back to production.