11

I'm starting work on a new site (8.x), and I'd like to be able to eliminate downtime if possible during production deployments.

What are my options for keeping my Content Delivery environment online during deployments? Code can often rely on content, so I typically end up with a delay while I wait for content to publish.

Assume a separate CM server and two CD servers behind a load balancer. I've mostly used TDS, but am looking at Unicorn this time around as well (In case that's important to the solution). I'm hosting on Azure - but I'm looking for Sitecore specific details.

Improve this question

5 Answers 5

Reset to default
14

We do our deployments as follows in our 8.1 environment using Team City, Octopus deploy and Unicorn (this is Simplified):

  1. a rewrite rule tells the load balancer to take CD1 out of the pool
  2. push the site NuGet packages to the CD and CM servers (we build this from Teamcity)
  3. deploy sitecore, the updated site code and serialised unicorn items to the CM sever
  4. deploy sitecore, the updated site code to CD1
  5. call unicorn to push the sitecore items into the master db and publish them to CD1
  6. ping a number of pages to warm up the site
  7. tell the load balancer to take CD2 out of the pool and put CD1 back in
  8. deploy sitecore and the updated site code to CD2
  9. call unicorn to publish to CD2
  10. ping a number of pages to warm up the site
  11. tell the load balancer to put CD2 back in the pool

At the end of this process we have two updated CD servers and an update CM server and users should have experienced no downtime. We do however have downtime on the CM server.

You may find you don't want to sync everything you need via unicorn so you could as ASURA says put in a manual pause in Octopus to do this between steps 6 and 7 and 10 and 11.

This works well for us, is easy to manage and doesn't require switching databases but might not cut it for some sites.

Improve this answer
1
  • Could you elaborate on step 9. call unicorn to publish to CD2? Do you mean in an automated manner?
    – koregan
    Commented Dec 12, 2017 at 13:27
9

I would highly recommend that you watch the following presentation by Mike Edwards:

Sitecore Nirvana - Continuous Deployment.

It's about two sets of databases being replicated. It all comes down to process at the end. You can definitely work through and come up with a process which works for you and your environment.

During deployments you would pause the replication, until the new deployment with code and content is verified.

Improve this answer
1
  • Please leave a comment if you are going to downvote an answer
    – Ben Golden
    Commented Oct 6, 2016 at 20:44
5

If your only need is to keep the CD nodes only and you are okay with downtime on the CM, you can achieve 100% uptime of your CDs during deployments using a second publishing target.

  • CD1 => Connected to Publishing Target 1
  • CD2 => Connected to Publishing Target 2

By swapping which CDs are in the Load Balancer you can take your time and control when you publish to each target. Once the publishing has been completed to that target, you can bring the CD into the load balancer and take the other CD out.

Depending on how often you need to deploy, you might want to keep these targets permanently. Otherwise, you can just use the secondary publishing target and update connection strings as needed.

Improve this answer
0
3

If you have two CD servers behind LB, you can

  • switch OFF 1st CD,
  • clone databases and update content
  • change connection strings on 1st CD
  • update code of 1st CD
  • switch ON 1st CD,

Later you can repeat that procedure for 2nd CD (skip step with databases, you will just switch connections strings as you already have dbs with new contnent used by 1st CD)

Improve this answer
3
  • Cloning databases seems unnecessarily complicated... Were you able to automate this?
    – Chris Berg
    Commented Oct 7, 2016 at 13:33
  • How do you want do it if you have code-to-content dependency? You cannot update content first as both instances uses the same db and publicly exposed instance might return errors with new content. And the same with code, without new content it will not work. No, I didn't automate that because I needed clone only few times. Of course we are talking about the worst case scenario, normally I do it without cloning because changes are not critical, so I only disconnect instance from LB, install update package and done.
    – Alan Płócieniak
    Commented Oct 7, 2016 at 18:33
  • That's the piece I was missing - aseabridge's answer suggests multiple publishing targets - giving each CD its own database.
    – Chris Berg
    Commented Oct 7, 2016 at 19:55
2

Although this post was asked a year ago, I guess it's still worth to comment as every project has it's own flavor of deployment.

This is what we do in our latest project whenever we want to deployment the hotfixes/change requests to Content Deliveries (CD) without downtime, as follow in order.

Environments:

PROD - Production Environment (Active) : 2 CD servers

DR - Disaster Recovery Environment (Inactive) : 2 CD servers

.

Deployment Tools:

Code Repository: Bitbucket/Github/TFS

TFS Online: Build

Octopus Deploy: Manual/CI deployment

  1. Conduct Octopus Deploy to DR environment, test and confirm if as expected.
    • As of this step, the DR CM/CD servers are accessible internal only. There's no downtime as the active servers are the PROD servers.
  2. Once the test are all confirmed passed, from A10 (Load Balancer), enable the 2 DR CD servers
    • All 4 PROD and DR servers are up and serving the end users.
  3. Drain stop the 2 PROD CD servers, wait for the concurrent users to shift the their session to the 2 DR CD servers.
    • As of this step, the active servers are the DR CD servers with the latest hotfix/change requests, and the PROD servers are accessible internal only.
  4. Conduct another Octopus deploy to the PROD environment, test and confirm if as expected.
  5. Once the test are all confirmed passed, switch back the PROD as the active servers via A10 Load balanacer control panel.

With regards to the connectionstrings, our datasources are pointing to the Alias of the Database servers instead of using the master/slave DB servers hence the change to the connectionstring is a one time change only.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.