Strategies for managing feature flags

It’s a well-known fact that deploying any code to production involves some technical risks. This is especially true when deploying or releasing features to users, as things might not always turn out as planned. For instance, the feature might not perform as expected, bugs might emerge after its release, or some other technical issue might arise.

Feature flags are one way we can mitigate and prevent some of these challenges from popping up at release time. Feature flags give us more control when we deploy new features and code. They enable us to perform testing more seamlessly, release features gradually, and keep those first-deployment hiccups isolated from the majority of our users.

In this article, we’ll explore what feature flags are, how to implement them, and some strategies for managing them.

What Are Feature Flags?

Feature flags, also known as feature switches, enable teams to turn certain features on and off during runtime without having to redeploy new code.

Feature flagging as a concept is relatively uncomplicated. We wrap our deployed code and features in conditionals that enable us to select who can see our features — and when they can see them. We can think of feature flags as a way of toggling feature visibility and access on and off.

The ability to enable or disable different pieces of code within an application on command lets us selectively enable or disable specific features without making significant changes to the software or code. This allows us to deploy code to production in a controlled manner. Additionally, it ensures that we can safely and easily roll back releases when the need arises.

Feature flags are often used to ship the code for new features to a live environment without giving users access to it. Then, the features are gradually rolled out incrementally to users — giving us an opportunity to receive feedback early in case something goes wrong.

Implementing Feature Flags

There are several ways to go about implementing and managing our feature flags. The simplest method of implementing them is by adding conditional if-else feature branch statements directly into our code.

This is done by storing the desired boolean value of the feature flag in a variable and then using the variable to create a custom feature branch. This feature branch then checks the status of the variable before executing the code for that functionality.

While this method is simple to use, it can quickly become cumbersome when working at scale. The code also requires manual intervention if we want to change the status of a feature flag.

Instead of manually implementing these if-else statements, there are several more efficient strategies we can use instead to manage our feature flags.

Use Config Files or a Database

Rather than hard-coding loops, we can implement a feature flagging system that’s controlled by config files or a database that stores the state of feature flags. This enables us to retrieve their values and alter our code flow when the value changes.

Using config files or a database makes it easier to configure and update our feature flags from one place. However, a concern here is that this process is generally restricted to software engineers. This creates blockers to product managers and designers while they wait for requests to be brought into a sprint. At Linktree, it has been useful to provide a feature flag management system which empowers everyone with the ability to update feature flags.

Build an Admin Dashboard

We can also consider building an admin dashboard for improved visibility and the ability to make quick changes. Having an admin dashboard or management system in place makes it easier and more convenient for us, our DevOps team, and other teams (like product development, design or marketing) to interact with these feature flags.

An admin dashboard makes it easier for us and others within our organization to keep track of changes made to our feature flags. Before settling into this approach, consider if this is a quick win or something that requires building out over time. If the latter, this will distract from roadmap progress. Is this slowing down manageable? Can the squad still maintain reasonable progress on deliverables?

Feature flags are a powerful technique that empowers teams and helps us avoid risks that accompany deployment.

Build a Control Access System

Security in the technical world is a central consideration, so controlling who has access to the flags in our system is essential. Using an unsecured management system exposes the risk of the wrong feature going live due to unauthorized access to our feature flags. The roll-on effect might introduce breaking changes into production, create a confusing UX with unintentional redirects, and potentially create a data breach with legal implications around GDPR and revealing PII.

We can build a system for controlling access to our feature flags that can grant selective access to specific teams and employees, helping to eliminate the chances of improper feature release or unintended code deployment.

Implement an Audit Logging System

Building on the previous section, we can also consider implementing a logging system to enable auditing feature flag metadata, such as when a flag was enabled/disabled and by whom. Audit logs are a helpful way for us to track the changes made to our feature flags, when those changes were made, and who made them. They add visibility into feature flag flips providing fodder for debugging and PIRs. Additionally, audit logging systems enable us to control access to feature flags and more clearly determine who should have permissions (and who shouldn’t).

An audit logging system provides full visibility of any changes made to each feature flag, ensuring complete transparency.

Use a Feature Flag Management Service

For larger, more complex use cases, we might consider using a third party platform to provide feature flag services, such as LaunchDarkly, Rollout.io, Split.io, or ConfigCat.com. Building a feature flagging system may not be in our teams’ wheelhouse — plus, it distracts from our roadmap and core business purpose.

Feature flag management platforms will generally provide advanced feature flag capabilities out of the box. They might include enabling and disabling flags for specific users based on attributes like geo-location, email, squad or other membership, and the ability to perform A/B testing and to incrementally release new features. Capabilities, that at once, lowers stress and adds considerable control over the release process, and roll-back is a breeze too with a reverting flip milli-seconds away.

The more advanced the feature flag management system, the easier it is to turn things on and off from a remote dashboard. This can make managing feature flags faster and more intuitive than in-house solutions. Plus, feature flag management services are designed to help us implement feature flags as we scale, which can help us manage technical debt.

Conclusion

Feature flags can be implemented and managed in a variety of ways. One simple implementation strategy is to create a small feature flag by implementing if-else statements in our code. Another option is to roll your own and build a management tool that relies on config files or a database. However, the build process can quickly become a distraction from our teams’ development focus, so it’s wise to look into alternative strategies, like a third party integration.

Feature flags are a powerful technique that empowers teams and helps us avoid risks that accompany deployment. Regardless of whether you’re just getting started with feature flags or if you’re already using them, be sure you’ve determined the best strategy to implement and manage feature flags in your development cycle.

Finally, two other considerations when using feature flags are creating an approach to, and strategy for maintaining, naming conventions, and removing 100% released flags. That is a whole other article.