We have done this approach @ redweb when we deploy via Octopus on to our own hosted servers and it's work pretty well

If using Octopus/TeamCity a step that would be good that we have yet to implement would be running Selenium or Wraith tests after. We do this as part of our automated builds and find it works pretty well but you could have a step in Octopus that on failure of the selenium tests could auto rollback via steps configured to run when previous steps fail allowing it to be all automated

Thanks for the insight Scott! Sounds like a blog post ;)

Yeah, I love Octopus so will have to do one. The first one I was planning on was around the new A/B testing so if there's any chance of a preview that would be excellent, wink wink ;-p

I have described some of the concepts we use for zero downtime deployment of Episerver CMS websites here: https://tedgustaf.com/blog/2017/zero-downtime-deployment-of-episerver/

To accomplish something similar to deployment slots on-premise, you can set up two IIS instances and use a "server farm" to control which instance is the active production environment: https://kevinareed.com/2015/11/07/how-to-deploy-anything-in-iis-with-zero-downtime-on-a-single-server/

Thanks Ted, all useful info :)!

Hey David,

We normally deploy to new servers, behind another laod balancer.  We check that it works fine, and then switch the domain to point to the new load balancer.  This works most of the time, the only issue we normally have is adding new fields to the basket as this randomly breaks both versions.  Once switched to, we add any new blocks, etc.