Blue-Green Deployments

Blue-green deployments are primarily used to reduce the risk of downtime during a deployment. They are one of many proper feature management processes that, when coupled with feature flags, give developers even greater control over every feature release. Use this article as a guide on how to integrate feature flags into your blue-green deployments.

Blue-green deployments are a release technique that reduces downtime and risk by running two identical production environments–called, you guessed it, blue and green. At any time, only one of the environments is live and serving production traffic. The other environment is idle and can be used for testing or as a standby. 

‍

When to use them

A common use-case for a blue-green deployment is when your dev team is preparing for an updated release of your software. The deployment and testing of this software update will happen in the idle test environment so that your live environment is not affected until you’re confident the release will perform well. Once all of your new code is ready, simply switch the router so that all incoming requests go to the live version in the test environment instead of the live system. Eventually, the new version becomes the live system and the older version becomes idle. 

When coupled with feature flags, blue-green deployments become even more powerful as you can begin testing different features within the software updates on a more granular level. For example, when switching from a blue environment to a green one, you can have a feature turned on in the green environment once it’s live, and you can begin gradually rolling out that feature in the green environment until you’ve proven its performance and extend it to all users. 

Releasing with confidence

The biggest advantage of blue-green deployments is that there’s zero downtime with new changes, and clients won’t even notice when they’ve switched to a new environment. That information alone is enough to put your mind at ease, since blue-green deployments are often used for quite large, macro-level releases (I mean, I guess you could use a blue-green deployment to add a search bar to your site, but you probably wouldn’t…) 

But for an extra layer of assurance, blue-green deployments also make rolling a feature release back and reverting to the idle (previous) environment a seamless process. This means that if something goes wrong with the “green” version that was recently deployed, you can simply switch back to the “blue” version and take as much time as you need to mitigate the issue. (This is especially ideal if an issue were to arise on say, a Friday evening, and you don’t have the necessary coverage to fix the code until Monday morning.)

Ultimately, blue-green deployments give your team the confidence to know they always have at least one working version of your website/app/software release ready.