I recently worked on a client’s Kentico
9 site upgrade to Kentico 12.0.6. The client utilized Azure App Services which is the “Platform as a Service (PaaS)” flavor of Azure, to host and deploy their site using the cloud. We at Bizstream couldn’t be happier by this. Kentico and Azure PaaS work together hand in hand to provide the client with the most efficient and scalable solution possible. For more information on Kentico and Azure paired together, checkout Kentico’s documentation
We especially see the benefit of Azure when performing a Kentico site upgrade by utilizing Azure App Service deployment slots. For a more detailed walkthrough / explanation of App Service deployment slots, take a look at this article
; but to summarize, since the client has their production website/web app deployed to the production slot of the Azure App Service, an additional deployment slots can be used to deploy the upgraded site in a very efficient manner. As long as they have a standard tier Azure App Service Plan, (S1, S2, S3) or higher, the client is able to update their live site with nearly zero downtime. This is possible thanks to the nature of the deployment slots allowing for nearly instantaneous swapping between said slots; this is where the Kentico site upgrade comes into play.
The Process of Upgrading a Kentico Site without Azure
To properly understand the benefits of Azure and Kentico together, we first have to have knowledge of how a normal, non-Azure hosted site is upgraded. Let’s say we have a similar situation to the aforementioned client site upgrade in which the production Kentico 9 site is hosted on Azure and needs to be upgraded to the latest version of Kentico; in the case of our client, Kentico 12.0.6. Kentico provides extensive documentation on how to upgrade a site from prior versions as detailed here
(among other places of course). High-level, the upgrade process is as follows:
- Make a copy of the codebase and download it locally
- Create a copy of the database and modify the web config of the local codebase to point to the copied database
- Using the Kentico Upgrade Tool, run the needed upgrade scripts on the copied database and codebase
- Run the site locally and add site license, then ensure functionality, check the event log, deal with custom code, etc.
- Upload the upgraded code files to the Azure App Service filesystem (or through publishing via Visual Studio) and prepare to perform the upgrade on the production site
- Change the web config of the production site to point to the upgraded database (the copy from earlier) and copy the needed code files into production as well
- Rename the upgraded database if desired to match the original production database
Note that in no way does this cover every detail of the extensive process of upgrading a Kentico site properly, as Brian Mckiever details in his two-part blog series here (Part 1
, Part 2
The diagram Brian uses in Part 1 (shown below) accurately depicts the complexity of applying the upgrade to different environments.
The biggest downside of this process is the downtime during the production site being upgraded. No client ever desires to have downtime, though most understand that it is in many cases a “necessary evil” to complete the upgrade process; but that's where Azure PaaS has changed the game.
A Better Process: Azure App Service Deployment Slots
As mentioned earlier in this post regarding Azure App Service Deployment Slots; the client hosts their production site in the production deployment slot on the Azure App, but if they utilize a second deployment slot to “stage” the upgrade, the upgrade process is much more efficient. The image above shows an example of what deployment slots look like (per Microsoft's documentation on staging slots), and how simple it is to perform the swap. The steps we have tried are as follows:
- Make a copy of the codebase and download it locally and create a copy of the production database
- Create a new deployment slot in the Azure App Service
- Point the production slot web config to the cloned database
- Using the Kentico upgrade tool, we upgrade the codebase that we downloaded locally
- We then ran the needed Kentico upgrade scripts on the production database (not the copied database)
- Once the prior two steps completed successfully, run the site locally and add the site license
- Verify correct functionality and check the event log, deal with custom code, etc.
- Upload the upgraded code files to the deployment slot that you created in the second step
- Swap the production deployment slot and the created slot
To break down the process; by utilizing the deployment slots, we are able to limit downtime to two specific instances, both of which just long enough for the cache to refresh. The first instance is when we change the production slot web config to the backup (copied) database. The second instance occurs when we swap the deployment slots, essentially swapping the code/data behind the production URL, then refreshing the cache to show the change. All that being said, there is one “Gotcha” that should be addressed.
Avoid a Potential “Gotcha” with Azure
It is important to understand how Azure works under the covers before jumping into it blindly. The diagram below comes from Microsoft's documentation on a basic web application.
The Resource group is the container, the App Service is the platform for the application itself, the App Service plan provides the virtual machines to host the app, and within the App Service are the Deployment slots. The “Gotcha” is completely dependant on two things, the resource demand of the web application(s) running - such as the production website and the deployment slot we created in our example - and the available resources of the Resources Group dictated by the Service Plan tier. The resources (applies to both memory and CPU) are shared on the service plan level, meaning that all deployment slots share the same resources; so if the resource demand of all the deployment slots approaches or exceeds the available resources, the production site and the second deployment slot that we created will both slow down; which is never desired. I will note that as a general rule, Bizstream recommends at least the S3 Tier App Service Plan for most clients to mitigate the possibility of poor performance. That being said, during the upgrade process, we have found it to be beneficial to temporarily increase the resources during the upgrade by stepping up one tier to help mitigate any potential performance issue.
We at BizStream have done countless site upgrades over the 7 years that we have worked with Kentico, and Azure has completely changed the game. Utilizing the capability of deployment slots, we are able to greatly decrease the downtime on the production site, while also putting more control of the site in the client’s hands. If you would like to know more, don’t hesitate to reach out to the team with us on your next project.