Implementing blue-green deployment with Azure App Service deployment slots

Ana Carolina Manzan — Fri, 17 Jan 2025 20:52:04 +0000

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! 👋

Boost your IaC development with terraform console

Ana Carolina Manzan — Wed, 14 Aug 2024 01:23:59 +0000

Hi devs!

If you are a terraform user, you've likely already used some of the built-in functions of it, like concat, map or format.

Whilst using some of these functions, have you ever asked yourself which would be the output of the function or even thought about testing it before incorporating it to your codebase? Well, I did it, and in this post I'll show you how you can test these functions in a practical way using terraform CLI itself!

The terraform console command

The terraform console command offers us an interactive console to which we can use to test built-in functions.

To begin with the testing, start your terminal type terraform consoleand press enter. After executing the command, the console prompt will be loaded right away. We will start by testing the function max(8,5,42,12) with a list of values like we can see in the example below:

In this simple test, we could validate that using max function with 8, 5, 42 and 12 as inputs, we will get the number 42 as the ouput considering it is the highest number in the list.

I'll bring another test scenario here using split(“,”, “Testing,terraform,functions”). This function is responsible for splitting our text at each comma found and transforming it in a word list, as we can check in the following image:

In short: in addition to the output, terraform console also bring information about the output format as we may check above with the list represented by tolist([...]).

Interacting with files

More than just testing functions, we can also use terraform console to interact with Terraform files.

To illustrate it, I created a file called variables.tf right in the directory in which I'm performing my tests and included a variable called cidr in it.

I set a default value of 10.1.0.0/16 for this variable, because I want to use it to calculate subnet addresses; To calculate the addresses I will use the cidrsubnet function.

I would like to provide an example of a different usage of terraform console command. To do this, I will use it by adding a pipe after calling the desired function:

echo '[for i in range(1, 5) : cidrsubnet(var.cidr, 8, i)]' | terraform console

After running this code, we will obtain the results:

Conclusion

Terraform console can become a valuable tool in our daily basis as our infrastructure code base grows. It can be a powerful ally whenever we need to ensure that the code we are developing will produce the results we expect.

I hope this content can contribute to your journey, and if you enjoyed it please leave a comment or contact me through LinkedIn.