How Enterprise Clients Can Use Sitecore Azure PaaS to Simplify Blue/Green Deployments to Achieve Zero Downtime

Website applications are becoming increasingly complex and so are the production deployments involved to upgrade their code. Choosing the right release strategy and using a reliable, automated process are key factors for a DevOps team to mitigate the risks involved when promoting a new code release.

There are different strategies to release code in a Sitecore multi-server production environment. At Velir, we perform production deployments using two different release strategies: rolling deployments and blue/green deployments. In this blog post, we will examine both types. We’ll also delve into why blue/green deployments are extremely valuable for our enterprise clients and how Sitecore Azure PaaS simplifies the blue/green deployment strategy implementation.

Rolling Deployments

The rolling deployment release strategy is currently the more popular of the two processes and is generally the default process for on-premises infrastructure servers. To implement the rolling deployment release strategy, you’ll want to:

1. Take each server individually off of rotation in the load balancer.
2. Deploy the new code.
3. Test on the offline server.
4. If all tests pass, add the server back in the load balancer pool to receive incoming traffic.
5. Repeat the same process for each production server.

Note: While performing a rolling deployment, the application code that runs on different production servers can be different for a period of time (with some servers running the newer version of the code, while others are still running the older version). This scenario can introduce issues if backward compatibility is not taken into consideration during code development. For example, backward incompatibility is introduced in a Sitecore web application when an existing field of a Sitecore template is removed and the older version of the code is not checking for the existence of the field before using it.

Rolling deployments also pose a few other challenges. With rolling deployments comes the risk of downtimes. Downtimes can have a direct impact on business operations. They can cause the loss of the application service, impact a business’ reputation, and even worse, cause revenue loss (most directly if the web application has an ecommerce integration). Downtimes may also cause loss of data, for example, if they occur while users are submitting data.

Additionally, it’s harder to rollback with rolling deployments than with blue/green deployments because the original instance is overridden with the new code changes, which means you need to deploy the old code again in order to rollback.

Blue/Green Deployments

Upgrades in one area of technology often influence processes in other areas. Such is the case here, where the increasing popularity of PaaS (Platform as a Service) makes blue/green deployments more viable. A blue/green deployment is a strategy that runs two identical production environments: "blue" and "green." At any one time, only one of them is live and serving production traffic. Since testing and validation are performed on a passive environment and the swap between the two environments can be done relatively fast, the blue/green deployment strategy can be considered a zero-downtime deployment strategy. The Cloud (like Azure) offers some automation out of the box to perform the swap.

The passive environment continues to run the old code and it can be easily used as a rollback in the unfortunate event that an issue is found on the active production environment. The blue/green deployment release strategy completely solves the issue of having backward incompatibility, since the new code release is promoted to all active servers at once. If you have a lot of production servers, it is cheaper to duplicate them in the Cloud than on premises.

To implement the blue/green deployment release strategy, you’ll want to:

1. Start with two identical production environments labeled "blue" and "green" where each environment can be a single server or a cluster of servers. Note: Only one environment is active and receives incoming web traffic, while the other environment is passive.
2. Deploy the new code release on the passive environment, where it gets tested.
3. Once the release is validated, route incoming web traffic to the passive environment which now becomes active, while making the previously active environment passive.

Blue/Green Deployments with Sitecore Azure PaaS 

While rolling deployments don't present any particular architectural challenges, the blue/green deployments require two identical, decoupled environments. Sitecore already offers the architectural concept of decoupling the authoring environment and the content delivery environment, providing the usage of different databases (master database and web database) and their indexes for each environment. The same concept can be used to decouple two identical production environments, creating copies of the databases and indexes.

Unless the client has very active authoring activity in Sitecore, and client authors cannot be inactive during a production deployment, the Sitecore authoring environment might not necessarily require a blue/green deployment strategy. This strategy makes more sense for the content delivery environment that processes public incoming traffic from users and visitors and is more sensitive to downtime.

With this assumption in mind, only the web database and any index related to the web database need to be duplicated. The blue content delivery environment points to the "blue" copies of the web database and the web indexes. The green content delivery environment points to the "green" copies of the web database and the web indexes. The usage of a configuration management solution simplifies this setup and guarantees that the correct database and indexes configuration is used for each environment.

In the Sitecore Content Authoring instance, there are three publishing targets, one for each web database: "authoring," "passive," and "active." The passive and active publishing targets are renamed every time a swap of the deployment slots is performed. 

Deployment Process 

Any deployment process should be automated as much as possible to guarantee integrity and traceability when promoting code releases from testing environments to production.

To perform a blue/green deployment for the content delivery environment of a Sitecore Azure PaaS solution, you’ll want to:

1. Identify the passive deployment slot where the new release will be deployed to. The Microsoft Azure API doesn't expose this information, but the passive slot can be detected using a custom labelling solution in a static file hosted in the web application. 
2. Compile and properly configure the code for the correct passive deployment slot. 
3. Deploy code to the passive slot. 
4. Publish content to the passive slot web database (unless already kept up-to-date by content authors). 
5. Perform application testing on the passive slot. This can be automated using an automated testing solution, like Selenium, or performed manually. Since the testing is performed on a passive slot, there is no strict time contingency to perform this task as is necessary with rolling deployments.  
6. Swap the deployment slots and rename the publishing targets in Sitecore. This step should be fully automated using the Microsoft Azure API to perform the swap. The renaming of the publishing targets can be automated as well, for example, creating a custom PowerShell script with the Sitecore PowerShell Extension module.

Note: This entire process can be automated and performed using a continuous delivery platform (i.e. Jenkins).

Architecture

The Microsoft Azure Cloud Platform offers an easy out-of-the-box solution to host blue/green production environments based on the usage of deployment slots for an app service and the native Azure swap functionality to swap deployment slots in/out of the app service container. 

Conclusion 

The blue/green deployment strategy is a great solution for enterprise clients’ applications, where any eventual downtime might have a big negative impact on the business. A fully-automated deployment solution is key to achieving managed and reliable production deployments. Sitecore Azure PaaS solutions naturally support this deployment strategy, making the entire deployment strategy easy to set up and use. 

Have you considered blue/green deployments for your site redesign? Join the discussion via the comments below or Tweet Us @Velir, and feel free to reach out to us with questions you may have. We’re passionate about the topic and would love to provide any insights we can to help you out!