Implementing blue-green deployment with Azure App Service deployment slots
Have you ever had to perform a deployment in your production environment after working hours, just to avoid having downtime? And maybe, even after your deployment was done, you realized your application version had issues that shouldn't be in the production environment and had to spend some time to perform a rollback? In this article, I want to provide you a simple solution to handle this problem using the Blue-green deployment strategy with Azure App Service deployment slots. What are deployment slots? First of all, we need to understand what "deployment slots" means and how this functionality can help us apply the Blue-green strategy in this scenario. Deployment slots is a whole functionality of Azure App Services that allows us to create a replica, a duplicate environment as a single live app coupled with our original web app that will behave as a staging environment that can receive new versions of our application. And how is this related to blue-green deployment strategy? Blue-green is a deployment strategy that claims we must have a replica of our productive environment in which we will deploy new versions of our application. After the deployment is done, we must shift the environments to grant that the newer version will be available for the users. I'm going to use an analogy to explain it better: imagine that you have 2 different kitchens in a restaurant, a blue one and a green one. The blue kitchen is functioning and serving the restaurant customers while you are having the green kitchen renewed. When the green kitchen renovation is done, you can then start using it to serve your customers, and if everything goes well, you will deactivate the blue kitchen. Let's get practical The first step we need to take in the direction of implementing it, is to create the necessary resources in Azure. We need to create a Web App within a Standard App Service Plan tier at least, in which we'll have access to the deployment slots functionality. To facilitate the App Service creation process, we will use Azure CLI to create the resources. Here is a quick explanation about the code below: from line 1 until line 5, we are creating variables that will hold information about the resources, like the location where they will be created, the resource group, app service plan, web app and slot names. You can exchange the values of the variables according to your preferences. In lines 7 to 10, we will create the resource group, the App Service Plan, the Web App and the Deployment Slot within the Web App we created before. The commands above can be executed either in your computer (after installing Azure CLI) or in Azure Portal using cloud shell. Here is a snapshot of how the resources should look like in Azure portal: Right after its creation, the Web App (on the left) and its deployment slot (on the right) will be waiting to receive the application code, as we can see below: Now with the infrastructure created, we need a pipeline that will deploy the application in the Web App and perform the swap operation between deployment slots. In the code above, we have the tasks that will perform the deployment and swap operations. We are going to focus on this two tasks of our pipeline for now, but you can find the whole pipeline code here and the full project code here. The first task is used to deploy our application into the WebApp. In this task, the application code will be sent to the Web App named bgapp into its slot stage. In the second task we are performing the swap operation. For this task, the command will shift the stage slot with the production Web App, which will then show the users the latest version of the application. Note that in this scenario, whenever we have a deployment, the swap will also happen right after it. If you wish or if it's applicable to your scenario, you can also perform the swap operation manually in Azure portal. Testing the pipeline Now with everything in place, set up and run the pipeline in Azure DevOps for the first time and check the final result. In this first pipeline run, we deployed the first version of the application with the blue feature, as we can see in the image above. Now, let's implement the green feature and deploy it. I will make some changes in the application code, commit and push it to Azure DevOps and the pipeline will be triggered from the changes in the main branch. The code was initially implemented in the stage deployment slot: And after the swap operation is done, we have the result of the new implementation: On the left side of the image, we have our Web App with the new version of the application with the green feature implemented. On the right side, we have the stage slot with the old version holding the blue feature. I hope this content can contribute to your journey, and if you enjoyed it please leave a comment or contact me in LinkedIn. See ya'll!
Have you ever had to perform a deployment in your production environment after working hours, just to avoid having downtime?
And maybe, even after your deployment was done, you realized your application version had issues that shouldn't be in the production environment and had to spend some time to perform a rollback?
In this article, I want to provide you a simple solution to handle this problem using the Blue-green deployment strategy with Azure App Service deployment slots.
What are deployment slots?
First of all, we need to understand what "deployment slots" means and how this functionality can help us apply the Blue-green strategy in this scenario.
Deployment slots is a whole functionality of Azure App Services that allows us to create a replica, a duplicate environment as a single live app coupled with our original web app that will behave as a staging environment that can receive new versions of our application.
And how is this related to blue-green deployment strategy?
Blue-green is a deployment strategy that claims we must have a replica of our productive environment in which we will deploy new versions of our application. After the deployment is done, we must shift the environments to grant that the newer version will be available for the users.
I'm going to use an analogy to explain it better: imagine that you have 2 different kitchens in a restaurant, a blue one and a green one. The blue kitchen is functioning and serving the restaurant customers while you are having the green kitchen renewed. When the green kitchen renovation is done, you can then start using it to serve your customers, and if everything goes well, you will deactivate the blue kitchen.
Let's get practical
The first step we need to take in the direction of implementing it, is to create the necessary resources in Azure. We need to create a Web App within a Standard App Service Plan tier at least, in which we'll have access to the deployment slots functionality.
To facilitate the App Service creation process, we will use Azure CLI to create the resources.
Here is a quick explanation about the code below: from line 1 until line 5, we are creating variables that will hold information about the resources, like the location where they will be created, the resource group, app service plan, web app and slot names. You can exchange the values of the variables according to your preferences.
In lines 7 to 10, we will create the resource group, the App Service Plan, the Web App and the Deployment Slot within the Web App we created before.
The commands above can be executed either in your computer (after installing Azure CLI) or in Azure Portal using cloud shell.
Here is a snapshot of how the resources should look like in Azure portal:
Right after its creation, the Web App (on the left) and its deployment slot (on the right) will be waiting to receive the application code, as we can see below:
Now with the infrastructure created, we need a pipeline that will deploy the application in the Web App and perform the swap operation between deployment slots.
In the code above, we have the tasks that will perform the deployment and swap operations. We are going to focus on this two tasks of our pipeline for now, but you can find the whole pipeline code here and the full project code here.
The first task is used to deploy our application into the WebApp. In this task, the application code will be sent to the Web App named bgapp into its slot stage.
In the second task we are performing the swap operation. For this task, the command will shift the stage slot with the production Web App, which will then show the users the latest version of the application.
Note that in this scenario, whenever we have a deployment, the swap will also happen right after it. If you wish or if it's applicable to your scenario, you can also perform the swap operation manually in Azure portal.
Testing the pipeline
Now with everything in place, set up and run the pipeline in Azure DevOps for the first time and check the final result.
In this first pipeline run, we deployed the first version of the application with the blue feature, as we can see in the image above.
Now, let's implement the green feature and deploy it. I will make some changes in the application code, commit and push it to Azure DevOps and the pipeline will be triggered from the changes in the main branch.
The code was initially implemented in the stage deployment slot:
And after the swap operation is done, we have the result of the new implementation:
On the left side of the image, we have our Web App with the new version of the application with the green feature implemented. On the right side, we have the stage slot with the old version holding the blue feature.
I hope this content can contribute to your journey, and if you enjoyed it please leave a comment or contact me in LinkedIn.
See ya'll!
