If you have any question about this blog post series or DevOps, feel free to contact me directly on Twitter : https://twitter.com/jcorioland.
This post is part of the series “VorlonJS – A Journey to DevOps”
In the previous post of this series we discussed about how Visual Studio Team Services and Release Management can be used to automate the creation of environments and the deployment of an application in these different environments.
If you’ve gone deeper into the Azure Resource Management templates that are used to deploy Vorlon.JS you may have noticed that we are using a different template for the production environment. This is because we are not deploying de application directly in the production web app but we are using a really nice feature of Azure Web App called “deployment slots”.
What are deployment slots?
Deployment slots are available if you are using the Standard or Premium App Service application plan. This feature allows to be able to deploy an application on a separate slot than the production one. Technically, a slot is just another web app running on the same service plan, with its own URL.
Using slots enable features like instant swapping or tests in production. Swapping is a really useful feature that make possible the upgrade to a new version of an application without service interruption / down time.
When deploying a new application, you always have a warm up time that could be more or less important and could impact the experience of your users. Using slots, it’s possible to deploy a new version of the application on a preview or staging slot, boot the application and then use the swap function that will swap the virtual IP address of the slots at the load balancers configuration level.
In the case of Vorlon.JS, the ARM template that describes the production environment is responsible for creating a Web App slot named staging and we use Release Management to deploy the application on this slot. After a deployment has occurred, we have two applications running in the production web app:
In this example, the production of Vorlon.JS (version 1.4) is deployed and used on the production slot of the Azure Web App named vorlonjs-production and accessible at http://vorlonjs-production.azurewebsites.net. The new version is 1.5 has been deployed on the staging slot and is accessible at http://vorlonjs-production-staging.azurewebsites.net.
Once the application is booted and we are done with our last checks on the staging slot we use the swap function to make the 1.5 version available on the production URL. As explained before, swapping does not deploy the 1.5 version to the production slot but only update the network configuration so it’s done in only a few seconds with no down time!
The swap function is available in the Azure Portal or using the command line (PowerShell or Azure Cross Platform CLI):
What are tests in production?
Test in production is a common practice that consist to redirect (transparently) a bunch of application’s users to a new version to get more feedback before making the application available for all the users.
With Azure App Service and deployment slots, implementing test in production is super easy. Once you have two versions of an application on different slots (see 1.4 and 1.5 versions of Vorlon.JS above), you just have to go in the Azure portal, in the routing settings and select the Traffic Routing option:
Then, you can configure Azure Web App routing to automatically redirect a percentage of users to another slot. For example, you can choose to redirect 30% of your production traffic on the staging slot so 30% of your regular users will use the new version of the application:
Note: once a user has been redirected to a given slot using traffic routing, a cookie is automatically set to ensure that he will not be redirected to another version the next time its browser sends an http request.
As explained in this article, Azure App Service deployment slots and traffic routing are really nice features to simplify the way you can upgrade an application with no service interruption. Tests in production, used with technologies like Azure Application Insights that allows to get information and metrics about application usage can be really helpful to determinate if a new version of the application will be really appreciated by the users or not.