Blue Green Deployment Strategy Explained

What is blue green deployment?

Blue green deployment is an application deployment strategy where the old and new releases of an application run in parallel on two identical production environments. For example, the older version runs in the blue environment, while testing for the new release happens in the green environment. Once tests are complete, a router or load balancer gradually re-routes requests to the green environment. Developers then run smoke tests before switching traffic permanently to the green environment.

The importance of blue green deployment for DevOps processes

A key requirement for an efficient DevOps pipeline is a way to deploy code to end users in an efficient manner. Continuous deployment of code changes helps release software fast, but can also push bugs and vulnerabilities that are missed by automated checks. Depending on the organization, responsibility for deployment of code falls to developers themselves, or an operations team that deploys build artifacts from the CI/CD pipeline.

In either case, teams need a way to quickly test new versions of applications in a sandbox environment, deploy them to users, then rollback to earlier versions if any issues are discovered in production. The cut-over to the new release requires careful consideration. Modern development teams frequently operate under a “release early and release often” philosophy, which is not compatible with more complex releases that require scheduling downtime during off-peak periods. The cut-over period needs to happen quickly to minimize downtime.

The basic idea behind blue green deployments is to set up two identical production environments, one for the previous version, and one for staging tests of the new version. The two environments can be different physical devices, different virtual machines, or an operating environment with separate IP addresses for each environment.

Blue green deployments bring a few benefits:

Instant rollbacks

The blue green approach allows for better detection of bugs due to the nearly identical nature of the staging and production environments. In case users find any issues with the new application running in the green environment, developers can instantly redirect requests to the older version running in the blue environment. This allows for instant rollbacks with no downtime for users.

Seamless upgrades

Blue green deployments automate the period between when software is “written” and when it’s live in production. In the initial upgrade, the green environment is used for testing, then serves as the production environment for the new version. The blue environment stays live for a period of time in case there is a need for rollbacks, then it’s deactivated and used for staging tests during the next rollout.

No downtime

As soon as developers are ready they can move new code into production during a period of regular use. There is no need to wait for slow times like late nights or weekends, and no need to schedule downtime. A side benefit is the staging environment can be used to test disaster recovery or as a backup.

Application load balancing is used to provide a seamless front end experience

Blue green deployments require careful implementation to ensure that users experience minimal impacts during cutover. One way to handle cutover is with a DNS record exchange, but this introduces limits because DNS propagation is not immediate.

Another approach is using application load balancing to slowly route traffic to the green environment, which allows for fine-tuned control of users. Load balancers can redirect traffic in case of errors in the green environment, and can be programmed to wait for a fixed duration before deactivating users or terminating users sessions in the blue environment.

Overall, this leads to a more seamless upgrade and fewer disruptions than forcing users to exit sessions before rerouting traffic. Load balancing may slow the process or fail for a small number of users, but most users don’t notice any downtime or differences.

How are blue green deployments different from canary deployments?

Unlike blue green deployments, canary deployments do not require separate environments for testing and production. DevOps or operations teams deploy the change to a small group of users (the “canary”), test the release, then decide whether to deploy the release to the entire user base.

Since they don’t use separate environments, canary deployments only require a small bit of extra infrastructure. They can be set up using a spare node or server, only what’s needed to support a small portion of the production environment and a small amount of traffic.

Blue green deployments using infrastructure as code (IAC)

Blue green deployments are a powerful technique for quickly releasing software while minimizing technological and business risks. They also require careful considerations around security. The complex architecture of applications and the environments they are deployed in, using web servers, containers, and microservices, and the use of tools for automating builds, tests, and deployments in the CI/CD pipeline, present the potential for misconfigurations, insecure environments, and surprises after cutover.

Traditional application security falls short when it comes to protecting IaC infrastructure. It focuses on the post-production application, which means bugs and vulnerabilities can end up affecting end users. Security teams operate separately from developers, which means that on the occasion security teams uncover issues, they rely on the development team for fixes, creating a bottleneck for delivery, and mismatched priorities for developers and security professionals. Furthermore, security operates as an external function to the development process rather than as an integrated part of the CI/CD pipeline.

Fortunately, there is a solution. Snyk Infrastructure as Code seamlessly integrates with the CI/CD pipeline to secure configurations before they go into production. It’s built with a developer-first focus, allowing automatic in-line code fixes. Snyk IaC includes automated tests for Terraform files and plans, AWS CloudFormation, Kubernetes configurations, Azure Resource Manager (ARM). Development teams can run IaC scans throughout CI/CD pipelines, in order to detect and fix configuration issues early. Drift testing with DriftCTL also detects post-deployment changes to infrastructure by people and tools outside of the regular flow. This brings ownership for build, test, and deployment security to developers, enabling DevSecOps principles using IaC tools for blue green deployments.