Blue-Green software deployment

One of the most important activities in working with IT systems is the release of code for production or software update. Not so long ago, new versions of the software were available on CDs released several times a year in the form of newsletters. With the advent of agile software development, cyclical releases appeared at the end of the sprint (e.g. once every two weeks).

Recently, Continuous Deployment has become more and more popular, where we can have new versions every day. How to deal with it?

One of the patterns to deal with frequent updates is the blue-green pattern. It is useful when implementing a new software version is quite risky. Even if we have good tests. Let’s also remember that other factors, such as firewall configuration, permissions, machine performance, etc. are also a part of the risk.

The aforementioned pattern assumes that we have at our disposal at least two environments: blue and green. These can be virtual machines, physical servers, two separate environments in the operating system or hosting accounts. It is important that they are different, but identical at the same time. At any time only one of them is active and has the latest version of the software.

We also need a load balancer or router. It will be responsible for redirecting the connection to the blue or green server. At the beginning it doesn’t matter which server will be selected.

The situation may be as follows:

1. On the green environment we throw the first version of the software. Everything works as it should. However, we decided to add some new features to the code and we want to implement it safely. At the moment we have a spare blue environment. So we put there our new code
2. At the moment there are two versions of the software. At present, users are using the green machine. So we have time to check if the new code does not cause any problems. Let’s remember that both environments are productive and use the same resources.
3. If we find out that everything is working properly, then on the router or load balancer we change the redirection of traffic from the green server to blue.
4. There are two possibilities at the moment. After the implementation everything works correctly and we leave it that way. However, if there are any problems, the whole rollback procedure boils down to redirecting traffic to the green server.
5. Subsequent implementations will take place on the same basis. Currently our main server is blue. So the new version of the software will be installed on the green server. And follow steps 1 – 4.

To sum up, thanks to the blue-green methodology we get:

• Implementation without any production downtime – the application will always be available for users
• Fast backup – we are able to return to the previous version in a short time. It boils down only to changing the router/balancer configuration.
• Safe implementation of new software without the risk of a more serious failure