Blue-Green Deployment - BloomReach Experience - Open Source CMS

Blue-Green Deployment

This documentation applies to Bloomreach Cloud 2 only

Introduction

Goal

Understand how to use blue-green deployment in Bloomreach Cloud and what the advantages and drawback of this approach are.

Background

Bloomreach Cloud is designed for blue-green deployment. Blue-green deployment is a release management approach based on running two similar production environments called Blue and Green. Production traffic is served by one of the environments (for example, Green). A new release is deployed in the other environment (for example, Blue). After deployment is successfully completed, production traffic routing is switched from the environment running the previous release (for example, Green) to the environment running the new release (for example, Blue).

Alternatively, rolling updates can be used to deploy backward-compatible distributions without downtime.
Please note that blue-green deployment takes up 2 (Blue and Green) of the maximum number of 4 environments in a stack. This means you have 2 environment left for testing, acceptance, etc.

Advantages

Reduced Risk

A new release can be verified after deployment before going live. In case of issues with the new release, production traffic is not affected.

Increased Availability

The environment running the current release keeps serving production traffic while the new release is being deployed and verified in the other environment. Switching production traffic to the new release is almost instant.

Easier Rollback

In case a new release turns out to issues after going live, production traffic can be switched back instantly to the environment running the previous release.

Drawbacks

Content Freeze Required

During the entire process of bringing a new release live, any data written to the repository and databases by the current release will get lost. Therefore, a content freeze must be enforced from before starting the backup of the current live environment until after production traffic has been switched to the other environment running the new release. A content freeze means that all content creation and modification, both by CMS users and any import processes, must be suspended. Also, any data collected by the website (forms, relevance data) during the content freeze must be manually recovered and migrated. All users must be logged out when the content freeze starts.

Procedure

  1. Deployment of the initial release in Green
    1. Create the Green environment.
    2. Deploy version 1.0.0 of your Bloomreach Experience Manager  in Green.
    3. Make Green the active environment by configuring the production domain to point to it.

    4. Create the Blue environment.
    5. Deploy version 1.0.0 of your Bloomreach Experience Manager in Blue.
  2. Deployment of a subsequent release in Blue
    1. Announce the start of a content freeze.
    2. Make a backup of Green.
    3. Restore the backup in Blue.
    4. Deploy version 1.1.0 of your Bloomreach Experience Manager in Blue.
    5. Verify that version 1.1.0 is running correctly in Blue.

      This verification should not contaminate the databases. Extensive testing should be done before this step in a separate acceptance environment.
    6. Make Blue the active environment by configuring the production domain to point to it.

    7. Announce the end of the content freeze.
    8. Monitor stability of Blue now that it is handling production traffic.
    9. Once version 1.1.0 has proven to be stable in Blue, deploy version 1.1.0 in Green so the two environments are in sync. This way Blue can act as a fail-over environment in case Green has unexpected problems, although its content is outdated. It also makes the next deployment in Green more reliable.
  3. Deployment of a subsequent release in Green
    1. Announce the start of a content freeze.
    2. Make a backup of Blue.
    3. Restore the backup in Green.
    4. Deploy version 1.2.0 of your Bloomreach Experience Manager in Green.
    5. Verify that version 1.2.0 is running correctly in Green.

      This verification should not contaminate the databases. Extensive testing should be done before this step in a separate acceptance environment.
    6. Make Green the active environment by configuring the production domain to point to it.

    7. Announce the end of the content freeze.
    8. Monitor stability of Gree now that it is handling production traffic.
    9. Once version 1.2.0 has proven to be stable in Green, deploy version 1.2.0 in Blue so the environments are in sync.

At this point, Deployment of a subsequent release in Blue and Deployment of a subsequent release in Green can be repeated indefinitely.

Keep Distributions In Sync

When you have deployed a new project release in one environment and want to bring the other environment up to date, always first deploy the new distribution and only then restore a backup of the already updated environment.

It is best to follow the procedure explained above which always brings the distribution in the inactive environment in sync with the distribution in the active environment.

Example

Suppose Blue and Green are both running project release 1.0.0 based on Bloomreach Experience Manager 11. You successfully update Blue to project release 2.0.0 based on Bloomreach Experience Manager 12. Next, you want to update Green to project release 2.0.0 as well. You should not first restore a backup of Blue into Green and then deploy the distribution 2.0.0. Green is still running 1.0.0/11 and restoring the backup of Blue based on 2.0.0/12 will redeploy the old distribution which will corrupt the database. Instead, first deploy the distribution 2.0.0 and then restore the backup of Blue.

  Database 1.0.0   Database 2.0.0

Distribution 1.0.0

OK
 
 
  deploy
   
Distribution 2.0.0
OK
restore
OK

Tips

Before deploying a new release in Blue or Green, test the release in a separate acceptance environment. This will speed up the actual testing during the blue-green deployment and allows for longer and more intensive testing, including tests which contaminate the databases.
If you announce the content freeze in the morning, you can start a new deployment with the scheduled backup made that night.
If you re-use (cycle) the existing blue/green environments, this will make restoring of the Elasticsearch index faster because it only needs to add what is missing from the previous active period.
When using the IP Filter plugin and switching production traffic from one environment to another, make sure the IP Filter hostnames configuration property is configured for the production hostname and not for the blue or green environment's hostname. Verify that the site is accessible from outside your corporate network after making the switch.
Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?