Share:

LinkedIn
WhatsApp
Facebook
Twitter
Reddit
Tumblr

Problem Statement

Nowadays enterprises want applications to be deployed in such way that new version of the application can be introduced to production without making user see that application went down even for some time. From the user’s and the company’s point of view it’s the best possible scenario of deployment since new features can be introduced and bugs can be eliminated without any outage.

Possible Solutions

Objective: Nowadays enterprises want applications to be deployed in such way that new version of the application can be introduced to production without making user see that application went down even for some time. From the user’s and the company’s point of view it’s the best possible scenario of deployment since new features can be introduced and bugs can be eliminated without any outage. It is more critical in case of sitecore, since enterprise not only have to deploy new functional change but also upgrade the version of sitecore time to time. There are below two strategies

A. Manual Strategy:
This is an old strategy where we can follow below steps to avoid any downtime: (Assumption is that we have multiple load balancer CD(content delivery) servers)

  1. Create the copy of web (web_deploy) and core (core_deploy) databases.
  2. Create additional solr cores for web (sitecore_web_index_deploy) and core (sitecore_core_index_deploy).
  3. Change authoring server configuration and point to above solr cores (sitecore_web_index_deploy and sitecore_core_index_deploy).
  4. Re-index web and core database solr cores.
  5. Change authoring server configuration and point back to original solr cores (sitecore_web_index and sitecore_web_index).
  6. Take CD1 out from load balancer.
  7. Change CD1 configuration and point to above created web and core databases along with solr cores.
  8. Add CD1 back to load balancer.
  9. Take CD2 out from load balancer.
  10. Change CD2 configuration and point to above created web and core databases along with solr cores.
  11. Add CD2 back to load balancer.
  12. Run database scripts on master, web and core databases.
  13. Deploy code change to authoring server.
  14. Re-index the content on solr for web and core database.
  15. Take CD1 out from load balancer.
  16. Deploy application/code changes to CD1 server.
  17. Change CD1 configuration and point back to original web and core databases along with solr cores.
  18. Add CD1 back to load balancer.
  19. Take CD2 out from load balancer.
  20. Deploy application/code changes to CD2 server.
  21. Change CD2 configuration and point back to original web and core databases along with solr cores.
  22. Add CD2 back to load balancer.


Pros:
This strategy doesn’t need additional infrastructure which in turn save cost.

Cons:
We need to involve larger team (application, infrastructure, sql admins etc.) every time whenever there is a deployment. Rollback is complex as we need to perform most of the above steps again.

B. Blue Green Strategy:
Blue Green is a “deployment strategy that relies on two identical production infrastructures that alternate between active and inactive. One environment is referred to as blue (inactive), and the duplicate environment is dubbed green (active)”.

In this approach, as you prepare a new release of your software you do your final stage of testing in the blue environment. Once the software is working in the blue environment, you switch the router so that all incoming requests go to the blue environment (blue becomes green) and the green one is now idle (green becomes blue).

Since the databases (sql and mongo) are shared resources between authoring and production and any change there can affect both. Additionally, since we are dealing with a CMS, we must expect that authors regularly introduce changes to the database. Challenge is more in case of sitecore since schema is controlled by sitecore. We can have below approach to overcome this:

  1. Synchronize content from green environment to blue environment.
  2. Upgrade new version of database changes in blue environment.
  3. Upgrade sitecore application servers in blue environment.
  4. Re-Index content on solr (content is new after synch) in blue environment.
  5. Test application thoroughly.
  6. Make blue environment live (green) and live environment ideal (blue)


Pros:
We don’t need to involve larger team (application, infrastructure, sql admins etc.) every time whenever there is a deployment.

Rollback is easier which can be achieved by just switching blue to green and green to blue.

Cons:
This strategy requires additional infrastructure which in turn cost more.

Pre-requisite for this strategy:

  1. Content author will not author during deployment.
  2. Session state is out-proc and session database is common between blue and green.

Share:

LinkedIn
WhatsApp
Facebook
Twitter
Reddit
Tumblr

Leave a Comment

Your email address will not be published. Required fields are marked *

Subscribe to Our Monthly Newsletter