How to Get Started With Feature Flags

Getting started with feature flags is fast and easy - especially compared to a lot of developer tools that can take more time to integrate into your workflow. 

You can usually find one or two easy wins with feature flags and get them working with just a few commands. Before diving into that though, let’s look at how to best plan ahead.

This article contains an excerpt from our eBook, The Basics: Feature Flags 101. If you like the content you see, stick around to the end where we’ll link the full eBook for you.

Before Getting Started

Before getting started, we recommend you have a brief discussion with your team to outline a good initial use case for feature flags. Some common ones are:

• Show or hide a button to access a new feature;
• Test a UI change;
• Try a new call to action to see how it performs; 
• Let users opt into an experimental use case.

Once you have picked a good initial use case, the next conversation to have is where you’ll implement the flag - meaning primarily in the front end, the back end, or a mix? The reason for this is because feature flags use SDKs you install in your code, and you’ll use different SDKs depending on the language of each service.

Your First Feature Flag

Once you’re ready to implement an initial feature flag, there are only three key steps, conceptually:

1. Install the SDK;
2. Create and code the flag;
3. Set up your flag rules.

You can go here for more detailed implementation instructions using Harness Feature Flags specifically, but we’ll first look at this at a higher level in this eBook.

Installing the SDK is as simple as picking the right language. Harness breaks down SDK types between server and client, as client SDKs will run in the user’s session, while server SDKs will live in your application and evaluate entirely locally.

Next, creating and coding the flag is really just a fancy if statement - wrapping the different code paths you want the different states of the flag to evaluate.

And, finally, creating the flag rules. If you’re not sure what that means, think of it this way: your feature flags get applied to end users of your application. We call those targets, other systems may call them users or sessions.  

Those targets have attributes that you define, such as email, licensing plan, location, or other custom characteristics. You can then use those attributes to decide which flags to serve them. For example:

• Show the true state of our “New UI” flag to all users in Texas;
• Show the 14 Day Trial state of our “Special Offer” flag to all users on the free plan;
• Lastly, show the true state of our “New Offer Test” flag to all users globally, but turn it off tomorrow so we can review the data.

You have flexibility in designing these scenarios, because you can pick any attributes you want to be used for this type of targeting.

But, you can also keep it simple and enable or disable the flag across your entire application as well. This is great for launching new features - instead of a whole new deployment coordinated with your marketed press release time, just turn the flag on. Anyone can do it, and your engineers can keep working on the next big thing!

Conclusion

You’ve now seen how easy it is to get started with feature flags. Whether you’re looking to build something yourself or use a tool, we hope the information here has made it easier to understand the prerequisites and how to start on a solution. As we’ve stressed in the past - and continue stressing, feature flags pack a punch!

Whether you find yourself trying to solve a pressing problem in your software delivery process, to get more control over your customer-facing application experience, or to get ahead of the game and see how you can better leverage technology, feature flags can greatly impact how you approach software delivery and the effect it will have on your users.

Are you ready to learn more about feature flags? If so, download the full eBook here: The Basics: Feature Flags 101.