Blue-Green Deployments - What Are They and Why Are They Important?

Introduction

With all the higher-level patterns I wanted to go back to basics a little bit and look at Blue-Green deployments. Though it can be deemed a design pattern (we’d certainly have to keep it in mind when we design our application), it’s probably more of a deployment strategy.

What is a Blue-Green Deployment?

A blue-green deployment is a software deployment strategy that involves creating two identical production environments, one for the current production release (blue) and one for the new release (green). Traffic is initially routed to the blue environment. Once the green environment is tested and ready, traffic gets switched over to green. Now intense monitoring takes place, we’re talking people glued to Grafana dashboards watching for things like exceptions, abnormal performance spikes, etc.

This allows for a seamless transition with zero downtime, no need for an “under construction” page if you have a UI, it’s as simple as pointing the load balancer from one instance to another.

Let’s look at it in more detail:

1. Initial State:

   • The live production version of the application is running in the “blue” environment, serving user traffic.

   

2. Deployment:

   • CICD deploys new developer code to the “green” environment. This environment is entirely separate from the “blue” one and doesn’t receive any user traffic yet.

   

3. Testing and Verification:

   • After the deployment to the “green” environment is complete, thorough testing and verification of the new version is performed. This step is crucial to ensure that the new version functions as expected and meets the required quality standards.

   

4. Traffic Switching:

   • Once the new version is tested and deemed ready for production, a traffic switch is performed. The user traffic is rerouted from the “blue” environment to the “green” environment. Now, the new version is serving live traffic.

   

5. Monitoring:

   • The system is closely monitored after the traffic switch to ensure everything is working correctly. Any issues or discrepancies can be quickly addressed, and if any critical problems arise, it is possible to switch back to the “blue” environment swiftly.

   

6. Rollback (Optional):

   • If any issues arise and the new version in the “green” environment proves problematic, a rollback to the previous “blue” version can be executed immediately to revert to the stable state.

7. Future Deployments:

   • Going forward, any subsequent updates or changes will follow the same process, with the “blue” and “green” roles swapped. The “green” environment becomes the new stable version, and a new version is deployed to the “blue” environment for testing.

   

Why are Blue-Green Deployments Important?

• Zero Downtime: Users experience no downtime during the deployment since the switch from the old version to the new version is instantaneous.
• Reduced Risk: The ability to quickly switch back to the previous version if issues arise ensures a lower risk of extended service disruption.
• Testing in Production-like Environment: The “green” environment, where the new version is deployed, replicates the production environment closely, enabling more accurate testing and validation.
• Easy Rollback: The deployment process includes a straightforward rollback mechanism, which adds a safety net in case of unexpected problems.

How do I put together my own Blue-Green deployments?

If you’re hosting a Webapp on Azure, it’s as simple as setting up and utilising deployment slots correctly. It makes the whole process fairly simple, read more here: https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots

If you’re looking at a more manual approach, the process involves setting up two identical production environments, one for the current release and one for the new release. The blue environment is the current production environment that is handling all traffic. The green environment is the new environment that is not yet handling any traffic.

Once the new release is ready, traffic is switched to the green environment. This can be done using a load balancer or DNS switch. The blue environment is then updated with the new release and becomes the new green environment. This process can be repeated for future releases.

Conclusion

Blue-green deployments are a popular strategy for deploying applications that minimise the risk of downtime and allow for continuous delivery. By creating two identical production environments, developers can ensure that the new release is stable and working properly before it is exposed to the public. By using a load balancer or DNS switch, traffic can be seamlessly switched between environments.