Blue-green deployment

What is blue-green deployment?

Blue-green deployment is a software development technique that utilizes two production environments (a "blue environment" and a "green environment") to make the software deployment process safer. It is a relatively complex deployment strategy but effectively minimizes downtime when updating your application in production. It is also very useful for product experimentation

The two production environments are kept as identical as possible. It pushes the newly deployed code to the currently inactive environment. Once the new changes have been tested in production, a router switches to point to the environment where the new changes are live, making for a smooth cut-over.

A blue-green deployment strategy allows you to update your application in production with minimal downtime. It works by deploying two identical copies of your application, one called "blue" and the other called "green." The blue copy is the current production version of your application, and the green is the new version you want to deploy. You assign some of your servers to host a new version of the application and the remaining servers to host the previous version.

Once the green copy is deployed and tested, you can gradually shift traffic from the blue to the green. Start gradually, such as by routing 20% of traffic to the green copy and then increasing the percentage over time. It allows you to monitor for any problems before you switch over.

If you encounter a problem, you can quickly roll back to the blue copy by routing all traffic back to it. This is why blue-green deployment is referred to as a "zero-downtime" deployment strategy. 

With blue-green deployment you get: 

• No downtime: The switchover from blue to green is instantaneous. Customers don’t experience any downtime during the deployment phase since both environments are active and identical.  
• Rollback capability: In case of issues, you can easily switch back to the blue environment. 
• Risk mitigation: By having a fully tested environment (green) before directing live traffic to it, the risk of deploying faulty or buggy updates directly to the live system (blue) is significantly reduced.  

In essence, blue-green deployment significantly reduces downtime and risk associated with deploying new changes to a live system. 

How to use blue-green deployment?

Blue-green deployment is a complex deployment strategy. Have a well-defined plan since this can be more expensive than other deployment strategies, such as A/B testing. 

• Use scalable infrastructure. It will help you to reduce the overall costs. 
• Practice chaos engineering in a green environment. It'll allow you to test the reliability of your application without impacting your end users. 
• Manage database state carefully. It is one of the biggest challenges of blue-green deployment. 
• Change load balancers, not DNS. It will give you more control over the traffic routing process. 

Stages of a blue green deployment model 

Here are the 9 stages of a blue-green deployment model:

1. Setup environments: Create identical blue and green environments.

2. Deploy updates to green: Implement changes in the green environment.

3. Testing and validation: Conduct comprehensive testing on the green environment.

4. Verification and quality checks: Verify updates for performance and compatibility.

5. Switchover: Redirect live traffic from blue to green swiftly.

6. Monitoring (Post deployment): Continuously monitor green for issues or anomalies.

7. Rollback (if needed): Quickly revert to the stable blue environment if issues arise.

8. Promote green to blue: Once stable, make the green environment the new live production (blue).

9. Clean up and prepare for the next cycle: Reset and prepare a new green environment for future updates. 

This streamlined process ensures a seamless transition between environments, minimizing downtime and risks during updates or changes to the live system. 

Blue-green deployment use cases

Rollbacks

One of the main benefits of blue-green deployments is disaster recovery. Because there are two identical environments for production, if new changes are rolled out to one (say the blue version) and any issues are discovered, a router can just switch back to the other environment (green version) which has the old version of the code with zero downtime. 

Continuous integration/continuous delivery (CI/CD pipeline)

One of the goals of continuous integration (a DevOps technique) is to get software live as soon as possible and speed up the development process through automated testing and frequent code integration. Blue-green deployment is a deployment strategy that can help with this goal by allowing more code pushes to production while lowering the risk of new releases. 

Testing in production

There are often small compatibility differences between the staging environment and production, no matter how much effort is made to make them identical. For DevOps teams, this can lead to edge cases and bugs that can't be discovered until the code has been pushed to production. Blue-green deployment allows for testing in production by pushing new code to the actual production environment and seeing how it performs, before smoothly transitioning it to production traffic and actual users. 

Canary deployment

A canary release is when new changes are released to a small segment of your user base, rather than rolled out to everyone. Much like a canary in a coal mine, this small controlled test can be used to determine if there are any fatal errors in the new version of your code. Blue-green deployment can be used for such canary testing by simply having the router direct a percentage of your traffic to a new version of the code to see how it performs with live traffic, before rolling out the change to 100% of your users. 

A/B testing

Another potential use case for blue-green deployments is A/B testing. In this use case, you would load the new version of your code onto the blue environment and direct 50% of your user traffic to the blue version vs. your original green version. Then you can monitor how the two environments perform in terms of your key metrics, and use statistical analysis to determine the exact impact of your new application. 

Load balancing

Another potential use case for blue-green deployment is load balancing. If the blue/green deployment is set up in a way so that the two production environments are on separate servers (rather than a virtual machine) a router can easily balance traffic between the blue and green versions of the production environment since they are functionally identical.

What are the advantages of blue-green deployment? 

Here are some of the main advantages of this deployment method: 

Zero downtime: You can update your application in production without downtime with two identical copies running. You can switch traffic from one to the other.

Rollback: If you face any challenges with the new version of your application, roll back to the previous version easily.

Reduced risk: You can test the new version of your application in the green environment before you deploy it to production.

Controlled deployment: Get control over the deployment process. Decide how much traffic to route to the green environment, and monitor for any problems before you make the switch.

Scalability: Blue-green deployment can be easily scaled to accommodate more traffic by adding more servers to the green environment. 

Blue-green deployment example

Say your development team is working on a web app and wants to release a new feature but wants to eliminate any downtime and have a smooth transition to the new code. In addition to your staging environment, you would set up two identical production environments (a "blue version" and a "green version") with a router directing traffic to the green version.

Then you can push the new changes to the blue version of the production environment, and see how it performs in an actual production setting. It may turn out that there are bugs that only occur in your production setting, in which case you can easily go back to development with zero impact on your users.

Once you are confident with the performance of the new version of the application, you can then start to direct a percentage of your user traffic to the blue environment to run a canary test on actual users. If no issues are discovered, then you can route 100% of your traffic to the new environment, leading to a smooth feature release.

If any issues are discovered once the cutover has been made, then you can again easily route traffic back to the green environment which has the previous version of your code to execute an easy rollback.

Once you are confident that there are no issues with the new code, you can then clone the blue environment to the green one, so that you again have two identical production environments. You can then continue on the development lifecycle, or use the second server as a load balancer as needed if you see a spike in usage.

What are the disadvantages of blue-green deployment?

Here’re some of the main disadvantages:

More resources: It requires you to maintain two identical environments, which can be more expensive than other deployment strategies.

More coordination: You need to coordinate the deployment of the new version of the application to the green environment, as well as the switchover from the blue to the green.

Slower to switch over: It can be slower to switch over to different subsets than other deployment strategies, such as A/B testing. You need to drain all traffic from the blue environment before switching to the green.

Not for all applications: Blue-green deployment is not suitable for all applications. For example, applications that use a lot of states, such as databases.

Feature-level granularity: A green deployment process does not enable feature-level granularity. So, if you encounter a problem with a specific feature, you'll have to roll back the entire release, not just the affected feature. If you are deploying a large or complex application, it can be difficult to apply this method. 

Feature flags vs blue-green deployment

An alternative development approach to blue-green deployment is the use of feature flags or feature toggles as rolling deployments. With feature flags, new features and code are wrapped in conditional code that can be remotely turned on or off. This allows developers to roll out new features to production, and have an easy way to rollback without having to maintain two production environments. 

In addition to simple on/off functionality, feature flags can also be used for targeted rollouts, where a feature is enabled only for a specific segment of your user traffic. This allows for use cases such as canary deployments and A/B testing, again without having to maintain two separate production environments.

If you are looking for an easy workflow to get started with feature flags, Optimizely free feature flagging is a free feature flagging solution from Optimizely that allows you to quickly and safely implement feature toggles and A/B testing in your app. Optimizely Rollouts is available for the most popular languages & libraries including JavaScript, Ruby, Node, React, and Python. 

Get started today with free feature flagging!