Blue-green warm

My colleagues and I always incline our clients to fully automate the deployment process. Automation helps to reduce the number of conflicts and delays that arise in the process between the "completion" of the work on the program and the commissioning. Dave Farley and Jez Humble are finishing the book on Continuous Delivery on this topic. It is based on a variety of ideas that are generally associated with continuous integration and are pushing for the ability to quickly put software into the work. The chapter on the blue-green deploy attracted my attention, because this is one of the little-used methods, and I decided to briefly highlight it.

One of the tasks of automation of deployment is the transition from one state to another within oneself, with the transfer of software from the final testing stage to the current production. Usually this needs to be done quickly to minimize downtime. With a blue-green approach, you have two productions, as far as possible identical. At any time, one of them, say blue, is active. When preparing a new version of the software, you are doing the final testing in green production. You make sure that the program in this production works and configure the router so that all incoming requests go to the green operating environment - blue in the standby mode.

The blue-green patch also gives you the opportunity to quickly roll back to the old state: if something goes wrong, switch the router back to blue production. But you still have to cope with the missing transactions while green production is active, and, depending on the structure of the code, you can direct the transactions to both productions to keep blue as a backup, with active green. Or you can switch the application to read-only mode, before synchronization, run it for a while in this mode, and then switch to read-write mode. This may be enough to get rid of many unsolved problems.

The two environments must be completely independent, but as identical as possible. Sometimes it can be different computers, sometimes just two virtual machines running on one (or several) computers. They can also be a single operating environment, divided into separate zones with separate IP addresses.

After green production is in the works, and you are satisfied with its stability, you can use blue as staging to drive it through the final tests of the next deployment. When you're ready for the next release, you can switch from green to blue as well as switch from blue to green. In this configuration, both green and blue production regularly pass through three states — the actual application, the previous version (for rollback), and the staging of the next version.

The advantage of this approach is that this is the same basic mechanism that is needed for hot redundancy (hot-standby). It will allow you to test the disaster recovery procedure with each release. (I hope you release more often than you have disaster recovery).

The basic idea is to have two easily switchable environments, and there are plenty of ways to change details. One option is to make the switch by restarting the web server, and not through a router. The other is to use a single database, and blue-green switches to do for the web and application layer.

With databases with this approach there are often problems, especially if you need to change their logical structures to support the new version of software. The trick here is to share the warm changes in logical structures and update the application. To do this, you first need to apply database refactoring to change the structure to support the new and old versions of the application, stop these changes, check that everything works well, and you have a version of the previous state, and only then update the new version of the application. (And when the updates have already been fixed, remove the database support for the old version).

This approach has been around for a long time, but I do not see it being used frequently. A must. Name invented Dan North (Dan North) and Jez Humble (Jez Humble).

(Translation by Natalia Bass )