Planning zero-downtime deployments with Azure App Services and Azure DevOps

Introduction

Every web application at some point of its life cycle has to be updated for some reason: it may be changes in business requirements, rebranding, bug fixes, adopting new versions of the libraries it depends on, etc.

If all our users are from the same time zone, it’s quite easy to identify a maintenance time window that would allow us to take the application offline, apply the required changes and bring the application back online without affecting the operation.

When our application has users across different time zones, though, to take that application offline may not be an option.

This is where we’ll be required to do a zero-downtime deployment.

The process to do a zero-downtime deployment for a web application in Azure can be summarized as follows:

Define different deployment slots in Azure

When we create an App Service in Azure, we can specify different deployment slots. These deployment slots are isolated instances of our application, with their own configuration and unique URL.

Once we define at least one slot, the default slot is labeled as “Production”.

For more information please go to https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots

Identify the required changes

The next step we need to do is to identify exactly which changes need to be applied to the production environment to successfully update the application.

Do we need to update the database schema? Do we need to change the location from which the application is reading a file?
Are there other changes in the external resources used by the application?

This is really important for a successful deployment. If all the changes related to external resources are new locations to read files from, as long as the schema of those files remains the same, there are no extra steps to do other than updating the configuration settings for the file paths.

However, if we need to update the database schema, we have to make sure that the currently deployed application code is fully compatible with the updated database schema.

Since the existing code should be able to use the database exactly the same way as before the schema updates, the following considerations must be taken depending on the change we need to apply:

Are we going to add new columns to a table?

Before deploying the new application code:

• The new column should allow for null values or provide a default value.
• The stored procedures reading from this table should list the table’s columns instead of using expressions like SELECT * FROM… This is because the existing application code should receive exactly the same results when reading from the updated table.

Are we going to rename a column in a table?

Before deploying the new application code:

• A new column with the new name should be created.
• For each existing record, we should set the value for the new column to be the same as the value for the existing column.
• The stored procedures that insert or update records in the table should set the same value for both columns.

After deploying the new application code:

• The stored procedures that insert or update records in the table should set the value only for the new column.
• The old column can be deleted.

Are we going to delete a column from a table?

Before deploying the new application code:

• The stored procedures that insert or update records in the table should not set the value for the column.
• The stored procedures that read from the table should return a default value for the column.
• The old column can be deleted.

After deploying the new application code:

• The stored procedures that read from the table should no longer return a value for the column.

Are we going to change the signature of a stored procedure?

• If the change includes adding or removing parameters, or returning a different set of columns (or even an additional result set), we should consider it to be a new stored procedure. It should have either a totally new name, or it could keep the old name as part of the new one given that it also includes a version number. For example: “InsertCustomer_v2”.
• If the change only modifies the internal behavior of the procedure, without changes in its parameters or result’s structure, the existing procedure could be updated without additional steps.

Are we going to delete a stored procedure?

• The stored procedure should be deleted after the new application code is deployed.

Use slot swap in Azure DevOps

Azure DevOps provides us with the capability to swap slots in our release pipelines. This means we can have for example a slot named “Staging” and do a swap between “Staging” and “Production” slots from a task in Azure DevOps.

Doing a slot swap with “Production” as the target slot ensures that the “Production” slot doesn’t have downtime.

To do a slot swap in our release pipeline, we just need to add a task to the stage representing our production environment:

For more information on what exactly happens during a slot swap please go to https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#AboutConfiguration

There are two important things to consider when deploying through a slot swap:

• If the web application has any entries in the appsettings.json or web.config file that need to be transformed, we should transform the app settings to their values for “Production” while deploying to the source slot of the swap (in this example, “Staging”). We can’t do a transform in the configuration files while swapping slots.
• Since the source slot for the swap is required to have the same configuration as Production, it is recommended to have at least an additional slot that would allow us to test our changes before they´re deployed to Production. These additional slots can have totally different values in the appsettings.json or web.config file, allowing us to set up separate environments to safely test every change without affecting Production.

After following the process described so far, the different deployment slots for our App Service will be displayed in the Azure Portal like this:

NAME	STATUS	APP SERVICE PLAN	TRAFFIC %
SampleAppService PRODUCTION	Running	MyAppServicePlan	100
SampleAppService-dev	Running	MyAppServicePlan	0
SampleAppService-staging	Running	MyAppServicePlan	0

It’s recommended for our release pipeline to have the different stages configured to be deployed only after the previous one is deployed successfully.

It’s also recommended to configure pre-deployment approvals on each stage, especially in Production. That would allow us to test the web application with the same settings as Production, so we can catch any errors that may be happening on that specific configuration before they affect the end-users.

If we have integration and/or end-to-end tests in our project, it’s also a good idea to have the release pipeline run them and only deploy to Production once all these tests pass.

The stages in our release pipeline would look like this:

Conclusion

Planning a zero-downtime deployment is no trivial task. Once we identify the need for a zero-downtime deployment, the planning should ideally start during the early development of the changes we want to include in that deployment. This is mainly because part of the steps mentioned above includes using new names for existing external dependencies (like stored procedures) and making several changes to our Azure environment and Azure DevOps release pipeline.