Zero down time for Delivery & Authoring

A lot of people talk about zero downtime, but normally just in the context of Content Delivery. Either with Azure PAAS websites and swapping slots, or using Azure Traffic Manager to switch over to a different load balancer/set of VMs.

However one of my colleagues found this article, to achieve Zero* downtime for Content Authoring.
https://sitecorepocs.blogspot.com/2016/06/sitecore-zero-downtime-deployments.html

*Or as near to Zero as possible as the users Session state will expire, as Sitecore requires InProc session state provider on Content Authoring.

I brought up in the sitecore discussion club slack channel that this is an area would like to discuss further, as trying to schedule deployments out of hours isn’t great for those who are doing the deployment, and disruptive to the editors who are trying to enter content.
And was put in touch on Slack with the author.

Also at the last Sitecore Discussion club (http://sitecore.events/), the author of this article was there, and presented this idea to the group.

It was interesting to hear that this was created to avoid getting up early to deploy before the authors were in, and that has been used in production, so the idea works.

Although the architecture in the original post was for two websites running on a single machine, and using Lucene indexes, and MSMQ.
There is no reason this can’t be updated to use Azure Message Queue, two independent complete stacks (Content Delivery, Content Authoring, SolrCloud).

At the group we also discussed some of the limitations/ideas

rollbacks, as it stands would want to be confident before switching over, as no way without data loss to roll back. Unless add a similar queue going in reverse. Although hopefully with enough testing rollbacks shouldn’t be a frequent occurrence, so might be acceptable.
transformation layer, say a field had been renamed, a layer between deserializing the message, and applying it to sitecore, would allow the message to be intercepted and updated to the new deployments expected format.
recording content editoring activity like this, could provide a way to record/replay content authoring activities to simulate authoring load in a test environment.

It’s an idea worth exploring further, more updates as we try this out ourselves.