Exhale. It's done.
That massive feature is finally deployed and in production.
You're feeling good, the stakeholders are happy to hear of the release, and surely the users are thrilled, too... right? Right?!
Not 5 minutes later, you get a Slack notification. It's from Carla, the sweetest customer support person ever.
Wait.
That was in #general?! Oh no.
You frantically pull main and test locally. Yep, it's busted.
Great. "Help."
You found the issue.
Hotfix branch. Commit. Push.
PR's up.
Right.
Tough pill to swallow, but it's possible that you're introducing other issues with frenetic fixes... and there's no guarantee that you're not resolving all issues.
Even though it stings, you revert.
Now we wait 20 minutes for things to build and deploy into production.
How many problems did YOU see?
What Are Feature Flags?
Feature flags, also known as feature toggles, are a tool that enable development teams to separate feature delivery from feature release. Think of them as a magic switch. With a flick of this switch, you can turn a feature on or off without having to redeploy your code. Sounds fantastic, right?
But wait, there's more! Not only do feature flags allow you to control feature release, but they also give your product team the power to make release decisions. This means, you, my dear developer friends, can focus on what you do best: creating and delivering awesome features, knowing that the when and who of the release is taken care of.
Benefits of Using Feature Flags
- Gradual Rollout: With feature flags, you no longer need to play the all-or-nothing game. You can release features incrementally, exposing them to a small subset of users before a full-scale rollout. This allows you to test the waters, gauge user reactions, and make adjustments before your feature makes its grand debut. It's like having the ability to walk before you run.
- A/B Testing: Imagine being able to present two different versions of a feature to your users, then sit back and watch which one they prefer. That's A/B testing in a nutshell, and feature flags make that possible.
- Canary Releases: Named after the proverbial canaries in coal mines, a canary release exposes a new feature to a small group of users before a full-scale rollout. This allows you to monitor the performance and potential impact of a feature in a controlled environment. If your feature performs well, you get to gradually scale up to full release.
- Operational Rollback: When things don't go quite so well and the canary stops chirping, we get to turn the code off without needing to deploy! Our systems become more resilient, our stakeholders don't "help" (as much), and our users' experience is affected as little as possible.
Feature flags are the safety nets that catch you when you fall. They're working behind the scenes to make your development process smoother, faster, and more efficient.
Now, let's look at these benefits side by side.
| Benefit | Description |
|---|---|
| Gradual Rollout | Allows for incremental release of features, reducing the risk of full-scale rollout failures |
| A/B Testing | Enables real-time user feedback on different feature versions to aid in decision making |
| Canary Releases | Facilitates performance monitoring of new features in a controlled environment before full-scale deployment |
| Operational Rollback | Provides the ability to scale back or disable features that have unintended consequences. |
Implementing Feature Flags
Implementing feature flags isn't like rocket science...or even building Ikea furniture. Essentially, it involves wrapping your features (or parts of features) in conditional statements that check the status of the flag. There are a ton of feature flag management packages in many languages and some built into popular frameworks. There are flag management SaaS orgs that handle this for you. But, really, implementing these from scratch isn't much of a reach if you're into it.
Best Practices for Feature Flags
As the saying goes, "There's no such thing as a free lunch." (By the way, when I was doing some background work for this post, this saying is referred to as TANSTAAFL -- I'm struggling to believe this is real. Is this an acronym? Does it rhyme with "waffle" or is it a mouthful of an initialism? Seems dubious to me. I can get behind yagni, but tanstafle is a bit much.) When feature flags are no longer needed, the associated code with the unused logic branch AND the flag itself must be cleaned up and removed. If the clean up step is skipped, this is a sure way to end up with a tower of tech debt. The goal is a sleek, well-tuned codebase protected and enhanced by flags, not a bloated ball of mud.
Back to our example from the beginning. The most egregious problem IMO is letting the user be the conduit for release feedback. We need operational visibility. What problems did you see?
Top comments (2)
In the past several months my dev team implemented feature flags in our code base. This has added additional benefits beyond the operations side of when a feature is deployed. The great thing about feature flagging new functionality is that it allows new code to be introduced to the main code base continuously without causing harm to what already exists.
Example; My dev org has three pods. Each have been working on big features that just fully release this week. The deploy and enabling of the features went smooth because over the past few months they've never stopped checking in new code for their features. It wasn't just one final big code dump at the end into our main branch. Its been incremental commits all wrapped behind feature flags. None of the new code had impacted our bi-weekly release cycle for months. And then when the feature(s) is truly done, we just flipped the flag.
YES! Isn't it a wonderful thing?!
Make something terrifying into something that isn't even a blip on the radar. Even better to separating the deploy from the release!
Way to go @scriptmunkee!