Implement a Feature Flag in Four Steps Using LaunchDarkly
Save money, time, and effort by implementing the magic of feature flags
Hide and Show New Features
There are many reasons to implement a feature flag; A/B testing, product and marketing-driven releases, infrastructure migration, and many more.
For me though, feature flags take away the fear of failure. This is the fear that someone might not like what I’ve done, or that something might explode in the code when it goes live in production.
By implementing a code change inside a feature flag, I can easily show or hide a new feature by flipping the flag on a dashboard, at any time I want.
For example, when I finally choose to show the new feature to the world (or at least a few close friends ), I can rest assured that, if the code explodes in production or the changes in production aren’t as spectacular as they were when I was developing, I can quickly revert the change.
Side note: Feature flags are often also called feature toggles or switches and I’ve even seen them referred to as feature flippers.
In four steps, let’s take a walk through what it’s like to implement a LaunchDarkly feature flag for a small personal application.
1. Getting Started With LaunchDarkly (Free Trial)
The first step towards achieving feature flag magic was signing up for a free trial.
All I needed was an email address and the ability to think up a good password. I’m sure that LaunchDarkly support would have helped me if I had run into an issue though.
2. Identify the Language and Feature
The second step was identifying the programming language of the project and which feature I wanted to update.
I have a React project that creates inspiration cards for my friend, Bradlie. I want to change the banner to be more aligned with the style of the cards. I know that the code for the banner currently sits at the top level of my application, App.js.
Now I know what I need, which language my app is written in (React), and where the code lives.
3. Quickstart
The third step, if you’re anything like me, is to use the Quickstart to get a feature flag into the code, quickly. Isn’t that really what a Quickstart is for?
The Quickstart for LaunchDarkly is set up like a demo. I had never set up a feature flag so, for me, it was actually quite satisfying to see feature flags work after such little code implementation. I thought it was a great little introduction before I started this project.
However, now that I’ve identified my own project to add a feature flag to, I only need to use a portion of the Quickstart.
The Quickstart asked me to name my feature flag and choose a language and environment. To start, I only have a production and testing environment, but I can always add more environments later.
Side note: I wanted to name the feature awesome-new-header but had already said OK to new-header, so here we are.
Once my flag name, SDK language, and environment were chosen, I skipped the step to create a hello-react app and went straight into installing the LaunchDarkly SDK using my terminal:
npm install --save launchdarkly-react-client-sdk@2.13.0
It was then time to add the code! As the Quickstart suggests, I started with App.js and pasted in the import and export default....
Just after taking this screenshot, I did add a colon in between "email" and "User@email.com" on line 11. (Hopefully, by the time you read this that will be fixed in the sample code. I did let LaunchDarkly support know and they were very helpful and receptive of feedback.)
"email": "User@email"As you may have seen above, my header code was in App.js. In my opinion, it made more sense to turn the header into a component to keep the application cleaner and more organized. Thankfully, it also makes it easier to use the Quickstart if the header is a component.
I also moved the export default... to the bottom of the App.js file. Check out the beautiful final code for App.js!
After moving the header code into its own component, it was time to add the feature flag to the new header component.
I started by copying and pasting the relevant code into my codebase. (importing the LaunchDarkly withLDConsumer and the flags themselves, and the export default...)
I then created an if statement with the original code in the if block and the new code in the else block. In the end, I had a very lovely component with a feature flag.
Be aware that another thing I found in the sample code was that the flag that is returned by the wrapper is not new-header, but actually camelCase newHeader.
Once again, I did let LaunchDarkly support know and they were very helpful and receptive of feedback. Matt, a support engineer, even said that there’s a way to disable camel casing. You can find that information in the docs.
I’m currently manually controlling the flag by setting it to true (line 12) while I do my development work and I’ll need to remove that line before I deploy the code to production.
In the future, to ensure I don’t introduce the possible human error of not removing that line, Bonnie, from LaunchDarkly support, recommends creating a new developer environment for the project in the app.
This new environment will have access to the same flags (as flags are shared across all the environments) but the targeting/default rule for the flag is specific to the environment — so you can set the flag to return true every time for your new environment.
Then, you can use environment variables to determine which environment key (see keys in the Account settings tab) to use, depending on whether your app is running in a production or dev environment.
4. Flip the Switch
The last step is to control the flag using the LaunchDarkly dashboard.
As you can see from the terrific screenshots below, while the New Header flag was off, the original header was shown. To flip the toggle to on, I wrote a message about the change and had to type the name of the environment.
Tada! Now I can show my friends the new header and if they don’t like it, I can switch it back with the flip of a flag without worrying about spending days trying to get it back to its previous state. Days where my friend would have to look at a header they don’t like!
Conclusion
This introduction to feature flags was written for a very small application that likely won’t ever be deployed to a larger audience.
However, implementing feature flags for a more extensive application with a lot of users can save a company the time, money, and effort it takes to roll-back a feature that doesn’t behave the way they expect it to in production.
For example, when I started writing production code for a small company when I was first starting out, there was a very lengthy approval process for a new feature and an immense amount of testing that went into a feature before it was released.
Why? Because if, at any point after the code had been deployed, it was identified that there was a bug, or that someone in the approval chain didn’t like it, it had to be “hot-fixed” in production or sometimes even rolled back.
It took an incredible amount of time and effort to roll a feature back and doing a “hot-fix” in production can be risky.
I believe the company could have saved money, time, and effort if they had just implemented the magic of feature flags.
