Blue-green deployment is a software development technique which utilizes two production environments (a "blue environment" and a "green environment") in order to make the software deployment process easier and safer.
The two production environments are kept as identical as possible, and when new code is deployed, it is pushed to the environment that is currently inactive. Once the new changes have been tested in production, a router can then switch to point to the environment where the new changes are live, making for a smooth cut-over.
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.
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.
There are often small differences between the staging environment and production, no matter how much effort is made to make them identical. This can lead to edge cases and bugs which 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.
A canary deployment 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 new version of the code to see how it performs with live traffic, before rolling out the change to 100% of your users.
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.
Another potential use case for blue-green deployment is load balancing. If the blue/green deployment is setup 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.
Say your development team is working on a web app and want to release a new feature but want to eliminate any downtime and have a smooth transition to the new code. In addition to your staging environment, you would setup two identical production environments (a "blue version" and "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 to 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 in order 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 one 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 issue 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.
An alternative development approach to blue-green deployment is the use of feature flags or feature toggles. 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 way 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!