16 Jun

Powering Blue-Green Deployments with Feature Flags

Using feature flags for granular release control and risk mitigation

Blue-green deployments have long been a proven technique to mitigate risk in software releases.  By adding feature flags, developers are ushering in a new era of blue-green deployments, one with unprecedented granular control over feature releases.  This article discusses how to effectively integrate feature flags into your blue-green deployment process.

At its core, a blue-green deployment is a release practice that maintains two production environments called blue and green, switching between whether the blue or green environment is live.  The primary benefit of this approach is to mitigate risk and control the timing of releases. The blue version might have the new version and green the old version.  If something goes wrong, you can switch back to the more stable environment.

Blue Green Deployments Feature Flags LaunchDarkly

The old way of blue-green deployments was more of an all-or-none approach.  Traffic was funneled in a binary fashion, all to blue or all to green.  It was also focused around timing: you could determine when you wanted to switch traffic and then switch back if something went wrong.

Blue Green All or None Deployments Feature Flags LaunchDarkly

Blue-green deployments, therefore, are a macro level of risk mitigation.  You are not focusing on testing smaller features, like a new search bar, and it’s usually something controlled by your operations team, not development.

With this blue/green deployment methodology, we are placing the burden of risk mitigation on our system architecture to test different application versions.  Imagine if you just wanted to test a small search bar update, would you want to go through an entire versioning process of duplicating environments and routing traffic?  This method may be overly excessive for small changes, especially if you are practicing continuous delivery and releasing multiple times per week (or per day).

To get more refined release granularity, you can complement your blue/green deployment with feature flags.  These flags are conditionals (if/else statements) that compartmentalize code at the ‘feature level’, meaning you can control the display of particular features instead of relying on separate application versions.

blub/green deployments launchdarkly feature flags risk mitigation and testing

Using feature flags, you could still manage your traffic with a load balancer with the added benefit of gradually rolling out new features to your users.  For example, you could switch from green to blue with the feature flag turned “off” in blue.  Then, once traffic was flowing to blue, you can turn on the feature flag and gradually release the feature to 1%, 5%, 20%… of your users until you were satisfied with the performance and feedback.  

Coupling feature flags with blue/green deployments could be best used with major application releases (like upgrading from version 1 to version 2 of a platform).  However, for less substantial feature changes or gradual testing, you could utilize feature flags to manage feature releases within a single production environment.  This will allow you to continuously release small features while still mitigating risk.  It also allows you to release faster because you can practice continuous delivery while substantially reducing risk in the release phase.

02 Jun

Powering Continuous Delivery With Feature Flags

Continuous Delivery LaunchDarkly

Separating feature rollout from code deployment to mitigate risk in continuous delivery

We are in the era of continuous delivery, where we are expected to quickly deliver software that is stable and performant.  We see development teams embracing a suite of continuous integration/delivery tools to automate their testing and QA, all while deploying at an accelerated cadence.

However, no matter how hard we try to mitigate the risk of software delivery, almost all end-user software releases are strictly coupled with some form of code deployment. This means that companies must rely on testing and QA to identify all issues before a release hits production. It also means that companies primarily rely on version control systems or scraped together config files to control feature releases and mitigate risk.  For instance, many homegrown feature release systems rely on hard coded values read from config files.  These systems can work with a handful of configuration values, but accrue massive technical debt at scale and may require a full redeploy for any updates.

Once a release is in production, it is basically out in the wild.  Without proper controls, rolling back to previous versions becomes a code deployment exercise, requiring engineering expertise and increasing the potential for downtime. Continue reading “Powering Continuous Delivery With Feature Flags” »