How To: Blue/Green Deployments with ElectricFlow

ElectricFlow was designed to enable teams to streamline and to simplify their DevOps processes – from the most mundane automation workflows to the most complex and large-scale scenarios. As part of that, we’ve set to revolutionize one of the most nail-biting parts of software releases: deployments.

Aiming to make this process as boring, repeatable and push-button as possible, ElectricFlow boasts the industry’s most robust deployment automation feature set, providing several out-of-the-box ways to deploy applications that are designed to take the stress, guess work, and complex, one-off, scripting out of the equation. These include deployment options such as Smart Deploy, staging artifacts, and automatic error handling or process branching, as well as advanced deployment strategies and deployment policies – such as rolling deployments, blue/green, canary, and dark launch.

In this blog series, I provide step-by-step tutorials for each deployment pattern – which you can implement for your own application releases using our free community edition!

In my previous post I described some of the use cases for when you may want to use these advanced deployment strategies as a way to minimize risk and provided instructions for setting up Rolling Deployments in ElectricFlow. This week, I’d like to focus on another deployment strategy: Blue/Green Deployments.

What are Blue/Green Deployments

This deployment strategy reduces downtime and risk by running two identical Production environments, referred to as Blue and Green. The key difference between Rolling Deployment and Blue/Green Deployment is that there are two physically separate environments. At any given time, only one of these environments is ‘live’, serving all of the Production traffic.

Let’s say the currently live Production environment is the Green one. We will spin up a duplicate of that – the Blue environment – and deploy new versions of the application to that, which is currently not serving live traffic. Once the version deployed on Blue has been thoroughly tested and validated, and we see that it is stable and that the application is operating correctly, then all end-user Production traffic will be diverted to that environment, which is now live. After the switch, the Green environment becomes inactive, and can be either decommissioned, or used for deploying the next release that needs to be tested. Then the process is repeated when we’re ready to make the switch in Production, again.

Blue/Green Deployment Strategy

Blue/Green deployment strategy is especially compelling when using cloud environment, where the resources can be dynamically spun up/decommissioned depending on the need. This is in contrast to on-premises data centers or physical hardware, where you would need to over-provision and keep the hardware for the duplicated environment, even when it is idle. The Blue/Green strategy is also useful when it is advantageous – and for some organizations even mandatory from a regulatory perspective – to maintain a separate mirrored environment for disaster recovery.

While Blue/Green deployments makes it much simpler to recover from unforeseen deployment errors, as there are two separate environments, it does come with a higher resource costs, due to the environment duplication. This may make it less feasible for extremely large Production environments/footprint.

How to set up Blue/Green Deployments in ElectricFlow:

ElectricFlow allows you to model and trigger Blue/Green deployments in multiple ways, depending on your processes and environment setup. For this tutorial, we’ll cover the most straightforward option: creating separate Blue and Green environments in the product’s GUI.

  1. The separate environments we’re creating are identical in every respect, and each is modeled and set up independently.
  2. The environments can be created either prior to the deployment (if they are using static resources), or dynamically at the deployment runtime using environment templates.
  3. Modeling Blue and Green as separate environments also allows us to keep track of the component inventory independently so that users can always know what is deployed to the Blue vs. Green environments at any given time.
  4. Once the environment models for Blue and Green are defined, we will map them to the applications, and can then execute the Blue/Green deployment process, like any other deployments in ElectricFlow.

In the below example, we’re using Blue/Green Deployment to deploy to Production the “shopping cart” application of an eCommerce site. The current deployment process requires that the application is tested in Dev and QA environments before it is deployed to the Production environment – where the Blue/Green strategy is used.

Here are the steps for modeling Blue/Green deployment for this use case:

  1. Create four environments
  2. Map the environments to the application
  3. Create a pipeline with three stages
  4. Create three tasks for the PROD stage
  5. Run the pipeline

! Note: If you’re new to ElectricFlow and the platform’s object model and key areas of the application, you may want to start with this video and our step-by-step in-product tutorials (look for the Tutorials popup when you log in to the product).

1Creating Four Environments (DEV, QA, BLUE, and GREEN)

Create four environments named DEV, QA, BLUE, and GREEN.

Model Your Environments

Note: DEV, QA, BLUE, and GREEN are names for the environments in this use case. You can use any names you want for them as long as it is clear how they map to BLUE and GREEN.

2Mapping the Environments to the ShoppingCart Application

Select the ShoppingCart application (comes seeded in the product), and then map the application tiers to the corresponding environment tiers in DEV, QA, BLUE, and GREEN.

Map application tiers to environments


3Creating a Pipeline with Three Stages

Create a pipeline with three stages named DEV, QA and PROD.

Create a pipeline with three stages named DEV, QA and PROD.

4Creating Three Tasks for the PROD Stage

In the PROD stage, create three tasks, with the below details (the Task name is in bold):

  1. DeployShoppingCart –  This is another process task similar to what is in the DEV and QA stages with the environment name parameterized. The system will automatically switch deployments between the BLUE and GREEN environments.
  2. CertifyDeployment –  This is a manual step to review and certify the deployment.
  3. completePostCertificationTasks – This is an automation task to run any post-certification tasks, such as updating the load balancer and switching the environment in preparation for the next pipeline run (for example, update the TargetEnv parameter)

Pipeline tasks in Prod stage


5Run the Pipeline

In a Blue/Green deployment, before you run the pipeline, the GREEN environment is serving all of the Production traffic, and the BLUE environment is ready to be upgraded to the new software version.

  1. Before starting the deployment, set the RollingDeploy/TargetEnv property on the project to the first environment to which you want to deploy.
  2. RollingDeploy/TargetEnv  will be set to BLUE because the GREEN environment is currently catering to end-user traffic.

When the pipeline starts:

  1. The pipeline will start at the DEV stage and continue to the PROD stage.
  2. Once the deployment reaches the PROD stage, the application process task will deploy to the BLUE environment based on the property value $[/myProject/RollingDeploy/TargetEnv] , which was set to BLUE at the beginning of the run.
  3. Once the deployment task has completed, there is a manual step to functionally verify the deployment.If there was a need for some automated testing, those tasks can easily be added to the pipeline stage.
  4. Once the deployment completes successfully, switch the user traffic to the BLUE servers, and update the RollingDeploy/TargetEnv  property to GREEN. Setting the property value to GREEN will ensure that the next deployment will happen to the GREEN environment while the BLUE environment serves Production traffic.
 It’s that simple!

Get started with ElectricFlow and Blue/Green deployments for free:

Deploy Anything, Anywhere. FREE.

ElectricFlow - The most advanced DevOps Release Automation solution

Download ElectricFlow

The most advanced DevOps Release Automation solution

  • Automate deployments
  • Orchestrate your delivery pipeline
  • Support Microservices & Containers
  • Accelerate software releases

Download Now

Learn more about ElectricFlow

Use it free!

Avantika Mathur

Avantika Mathur

Avantika (Avan) Mathur is the product manager for ElectricFlow. She helps large enterprises across #Finserv, Retail, Embedded accelerate their #DevOps adoption, design complex automation solutions & optimize delivery pipelines. Avan holds a degree in Computer science. Previously, she was the Global Technical Account Manager for large customers at Electric Cloud. Prior to working at Electric Cloud, Avan worked as a software engineer at IBM for five years doing Linux kernel development.
Avantika Mathur

Share this:

Leave a Reply

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


Subscribe via RSS
Click here to subscribe to the Electric Cloud Blog via RSS

Subscribe to Blog via Email
Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Executive Leadership Workshop with Gary Gruver & Helen Beal
DevSecOps Workshop with John Willis

Continuous Delivery (#c9d9) Podcast

c9d9 Continuous Discussion on Agile, DevOps, and Continous Delivery

Next episode:

Episode 88: Model-Driven Pipelines

June 5, 10am PT