Blue/Green Feature Flags: Combining Operational and Development Best Practices to Achieve Progressive Delivery

LaunchDarkly
By Lev Lazinskiy   •   December 4, 2018
LaunchDarkly

Last week at re:Invent the AWS team announced some great improvements to their continuous delivery offerings for AWS Fargate and Amazon ECS. Notably, you can now use AWS CodeDeploy to configure blue/green deployments for these two services. We are excited to see AWS add this functionality as a first class part of their container service offering because it makes it easier than ever for AWS CodeDeploy users to achieve Progressive Delivery.

We've written about blue/green deployments as a strategy to enable Progressive Delivery. We've also had several talks at our Test in Production Meetup, which highlighted blue/green deployments as a way to test in production without sacrificing availability.

We talk to a lot of customers about how feature flags can complement blue/green deployments to complete the progressive delivery journey. At first glance these two practices appear to do the same thing, but there are some key differences in these approaches. The way we like to frame the conversation is that a blue/green deployment is an operational best practice that allows you to change your infrastructure with the minimum amount of risk. On the other hand, feature flagging is a development best practice that allows you to change any part of your application with the minimum amount of risk.

LaunchDarkly

“The blue/green deployment is an operational best practice that allows you to change your infrastructure with the minimum amount of risk. Whereas feature flagging is a development best practice that allows you to change any part of your application with the minimum amount of risk.”

Picture this: you just shipped five new features at the end of your two week sprint (great job!). Your operations team leveraged blue/green deployments to deliver the new version of your application out into production safely. At the end of your deployment you noticed that one out of the five features is resulting in a critical bug that causes 500 errors for 90% of all requests. What do you do?

If you only had blue/green deployments, you would roll back to the previous version of your software. This is great because you have quickly recovered from this production incident, but it's also bad because the other four features you delivered have also been rolled back and now you have to wait an additional two weeks to deliver them back out into production.

With feature flags, you could disable the problematic feature. This allows you to recover from this incident and allow the other four features to provide value to your customers. Everybody wins.

You can see why we feel strongly about combining blue/green deployments with feature flags—it's a great way to continuously deliver value to your customers with the minimum amount of risk.

You May Like
  •   BEST PRACTICESTesting in Production to Stay Safe and Sensible
  •   BEST PRACTICESWhat Is Continuous Testing? A Straightforward Introduction
MAY 14, 2021   •   BEST PRACTICESCloud Deployment Models: Explaining and Comparing the 5 Main Models
MAY 11, 2021   •   BEST PRACTICESWhat Is Deployment Automation, and Why Should You Care?
MAY 6, 2021   •   BEST PRACTICESRelease Testing Explained
MAY 4, 2021   •   BEST PRACTICESOrchestration vs. Automation in the Cloud: How to Use Both