The last few years have seen huge improvements in the speed of software development. Combined with the adoption of methodologies like Agile, this has resulted in more and more frequent deployment requests and releases. So how do DevOps teams provide the required CI/CD practices to support the speed and demands of these new technical capabilities and business strategies?
The Problem
Software development has improved dramatically over the last few years by establishing new paradigms, designs, and well-know practices. Additionally, companies have incorporated methodologies like Agile that result in more frequent releases, unlike the yearly releases that used to be the norm for updating monolith systems.
DevOps professionals have been working hard to keep up with the rapid evolution of software development. Nowadays, we have frameworks to provide automated deployments, maintain quality, and ensure security. Good examples of these frameworks are Jenkins and SonarQube. However, for modern solutions, the most frequent requirement is to have a no-downtime deployment when releasing a new version.
Solutions
In response to this challenge, a couple of strategies have been developed and successfully implemented. Some interesting examples include big bang deployment, rolling deployment, canary deployment, and blue-green deployment. In today's post, we'll take a closer look at blue-green deployment.
Blue-Green Deployment
Blue-green deployment was introduced by Dan North around 2010. The idea is to reduce deployment risks and avoid downtime that could cost companies millions. It also provides reliable and consistent environments for developing, as well as a QA team, mirroring the production environment. Another benefit of blue-green deployment is that it can be easily rolled back to the old version in case the new release exhibits unexpected behaviors.
How It Works
The idea for blue-green deployment is that there is a production environment (the blue environment) that is up and running. After ensuring that it is stable, we deploy a new environment (the green) in which we have the same version but idle. Both environments are managed by a load balancer, as shown below.
Image courtesy of ThePracticalDev
For the next release version, all changes will be applied and tested in the green environment. Once we determine the stability of the changes, the process to switch to the active environment can be executed by requesting the load balancer to migrate all sessions and incoming requests.
In some cases, the first step is to block the blue environment from receiving requests, keeping it alive until all active sessions are finished, while redirecting new requests to the green one. Another option is to migrate sessions at the same time. After the blue environment finishes the migration, we can set it as idle while the green environment assumes the production role.
Image courtesy of ThePracticalDev
Managing a database can be tricky, so mirroring can be very helpful to keep both the blue and the green environments synchronized. Sometimes both blue and green can share important resources, such as a database. Because of this, updating and keeping it compatible between releases is extremely important.
Image courtesy of cdn2
Last but not least, some applications use message queues, which can present a challenge. Message queues require special attention because queues need to be managed while switching from one environment to another. In most cases, message queues prevent the usage of blue-green deployment, so another deployment solution must be used instead.
Conclusion
As explained above, blue-green deployment can be easily implemented and provides several benefits like reducing risks and eliminating downtime (in most cases). Blue-green deployment is a colorful solution that can be implemented in many different ways, so DevOps teams can choose the solution that fits their scenario.
