How we implemented DevOps: testing a production environment with Azure Web App
Sometimes it becomes necessary to update the application without interrupting its work. Do Azure App Service deployment slots and traffic routing help in this? What is all this all about? Read under the cut.
In the previous article in this series, we discussed how Visual Studio Team Services and the Release Management tool can be used to automatically create the necessary environments and deploy applications to these environments.
')
If you pay attention to the content of the Azure Resource Management template that we use to deploy Vorlon.JS, you will notice that we are using a different template for the production environment . This is because we are not deploying the application directly to the Azure Web App, instead we use the very convenient Web App feature called Deployment Slots.
Deployment slots are available in the Azure App Service, starting with the Standard service plan. This feature allows you to deploy the application in a different slot than production. From a technical point of view, a slot is just another web application that runs in the same service plan and with its own URL.
Slots allow you to use features such as instant media switching (swapping) or testing in a production environment. Swap is a really useful feature that makes it possible to upgrade to a new version of the application without interruption of service and downtime.
When you deploy a new application, it always takes some time to “warm up”. This may affect the views of your users to one degree or another. Using slots, a new version of the application can be deployed in a separate staging slot, start the application, and then use the swap function, swapping the virtual IP addresses of slots at the load balancer configuration level.
In the case of Vorlon.JS, the ARM template, which describes the production environment, is responsible for creating a slot inside the Web App called staging, and we use the Release Management (tool) to deploy the application in this slot. As a result of the deployment, we will get two running web applications in our production instance of the Azure Web App:
In this example, the production version of the Vorlon.JS application (version 1.4) is deployed and used in the production slot of the Azure Web App under the name vorlonjs-production . The new version 1.5 is deployed in the staging slot called staging .
After launching the application and conducting final checks in the staging slot, we will use the swap function, and version 1.5 will be available at the URL. As mentioned above, the swap function does not deploy version 1.5 in the production slot, but only updates the network configuration, so everything will be done in a few seconds, without downtime.
The swap feature is available in the Azure portal or through the command line interface (PowerShell or Azure Cross Platform CLI):
Testing in production is a common practice, which is to redirect the group of selected users to the new version. This allows you to receive early and more advanced feedback before making the application available to all other users.
Azure App Service and deployment slots greatly simplify testing in a production environment. When you have two versions of the application in different slots (for example, Vorlon.JS 1.4 and 1.5, described above), you just need to go to the Azure portal and in the routing settings select the option Traffic Routing (Traffic Routing):
You can then configure Azure Web App routing so that a certain percentage of users are automatically redirected to a different slot. For example, you can redirect 30% of the production traffic of the application to the staging slot, that is, 30% of your users will use the new version of the application:
Note. After a user is redirected to this slot, a cookie is automatically created using the traffic routing function to ensure that the user is not redirected to another version when sending the next HTTP request from his browser.
As it became clear from this article, the Azure App Service deployment slots and the traffic routing function really allow you to update the application without interrupting its work. Testing in a production environment in combination with analytics tools, such as Azure Application Insights, provides information and the necessary metrics to determine whether the new version will be appreciated by users.
We continue the series of articles “How we implemented DevOps” from the Vorlon.JS team.
Vorlon.JS is a node.js-based tool that allows web developers a convenient way to remotely test, control and debug a web application, especially on mobile and embedded systems. In her blog on MSDN, the team described in detail the phased introduction of DevOps practices into the organization of work on Vorlon.JS and the selection of tools for solving daily tasks. Vorlon.JS is an open source project .
In the previous article in this series, we discussed how Visual Studio Team Services and the Release Management tool can be used to automatically create the necessary environments and deploy applications to these environments.
')
If you pay attention to the content of the Azure Resource Management template that we use to deploy Vorlon.JS, you will notice that we are using a different template for the production environment . This is because we are not deploying the application directly to the Azure Web App, instead we use the very convenient Web App feature called Deployment Slots.
What are deployment slots?
Deployment slots are available in the Azure App Service, starting with the Standard service plan. This feature allows you to deploy the application in a different slot than production. From a technical point of view, a slot is just another web application that runs in the same service plan and with its own URL.
Slots allow you to use features such as instant media switching (swapping) or testing in a production environment. Swap is a really useful feature that makes it possible to upgrade to a new version of the application without interruption of service and downtime.
When you deploy a new application, it always takes some time to “warm up”. This may affect the views of your users to one degree or another. Using slots, a new version of the application can be deployed in a separate staging slot, start the application, and then use the swap function, swapping the virtual IP addresses of slots at the load balancer configuration level.
In the case of Vorlon.JS, the ARM template, which describes the production environment, is responsible for creating a slot inside the Web App called staging, and we use the Release Management (tool) to deploy the application in this slot. As a result of the deployment, we will get two running web applications in our production instance of the Azure Web App:
In this example, the production version of the Vorlon.JS application (version 1.4) is deployed and used in the production slot of the Azure Web App under the name vorlonjs-production . The new version 1.5 is deployed in the staging slot called staging .
After launching the application and conducting final checks in the staging slot, we will use the swap function, and version 1.5 will be available at the URL. As mentioned above, the swap function does not deploy version 1.5 in the production slot, but only updates the network configuration, so everything will be done in a few seconds, without downtime.
The swap feature is available in the Azure portal or through the command line interface (PowerShell or Azure Cross Platform CLI):
What is testing in production?
Testing in production is a common practice, which is to redirect the group of selected users to the new version. This allows you to receive early and more advanced feedback before making the application available to all other users.
Azure App Service and deployment slots greatly simplify testing in a production environment. When you have two versions of the application in different slots (for example, Vorlon.JS 1.4 and 1.5, described above), you just need to go to the Azure portal and in the routing settings select the option Traffic Routing (Traffic Routing):
You can then configure Azure Web App routing so that a certain percentage of users are automatically redirected to a different slot. For example, you can redirect 30% of the production traffic of the application to the staging slot, that is, 30% of your users will use the new version of the application:
Note. After a user is redirected to this slot, a cookie is automatically created using the traffic routing function to ensure that the user is not redirected to another version when sending the next HTTP request from his browser.
Conclusion
As it became clear from this article, the Azure App Service deployment slots and the traffic routing function really allow you to update the application without interrupting its work. Testing in a production environment in combination with analytics tools, such as Azure Application Insights, provides information and the necessary metrics to determine whether the new version will be appreciated by users.
Source: https://habr.com/ru/post/343592/
All Articles