Wednesday 22 June 2016

Sitecore Zero Downtime Deployments

Sitecore is an extremely flexible platform for managing an organisation's web presence. As such, when enhancements and upgrades are requried, deployments need to be scheduled and coordinated. However, in most scenarios I've heard of this inevitably leads to downtime (maintenance mode) of the site in one form or another. Additionally, if required, roll-back can be costly both in terms of time and the technical resources required to undertake the activity.

This post is about mitigating the risk of a roll-back and allowing for deployments to go ahead without the need for a content freeze or for the website to go into maintenance mode.

Essentially, the following steps are undertaken when deployments are made:
  1. Deploy new version of the site to the same IIS node as the live version: 
    1. Ensure isolation by configuring unique apppool and website name/location 
    2. Ensure default binding is on a "test" port such as 81 
  2. Perform database maintenance tasks: 
    1. Backup core database 
    2. Restore core datebase with a unique name 
    3. Repeat for the master and web databases 
  3. Configure CM and CD instances as requried: 
    1. Each new deployment can go with it's own data folder or just use the same as every other deployment 
    2. Configure connection strings such that they point to the new core, master, and web databases 
  4. Deploy code assets as required - cshtml, config, dll, etc etc 
  5. Deploy Sitecore assets as required - (templates, settings, looksups, rules etc etc) 
    1. This could be by packing up all new features or it could be by using Unicorn 
  6. Now that everything is wired up, test the site by hitting <URL>:81 
    1. 81 is an example of a test port but you could choose any other port 
  7. Change bindings such that the new site uses a live port and the old site is stopped
These steps allow for an "in situ" deployment of new functionality and also allow for rollback - if required - by simply making the previous site live again (stopping the current live site, and starting the previous live site). However, in all of this, there is one crucial element that is not addressed and that is the need for ensuring that no content is lost whilst the deployment is occuring.

This is where some magic comes in. I won't go into the detail here as the sequence diagram says more than a thousand words:
0 Downtime deployment sequence
As the sequence diagram shows, there are 2 components to 0 downtime deployments:
1 - Serialise content changes - (creates, updates and deletes) upon detection of a new site being provisioned
2 - Watch MSMQ such that content changes are deserialised.

The general gist of the code is at 0 Downtime Gist

Of course you can also employ deployment tools such as Octopus Deploy to fast track the deployment process but the magic is actually done in the SerialiseContent pipeline and MSMQWatcher job.

No comments:

Post a Comment