Feature Flag Best Practices

Chapter 10. Best Practice #8: Have a Plan for Working with Flags at Scale

As engineers from different teams create, change, and roll out feature flags across the application stack, tracking and cleanup can get out of hand over time. Maintaining the who/what/why of feature flags and establishing a basic process for identification and tracking will reduce complexity down the road.

Naming Your Flags

Defining a pattern or naming convention for naming your feature flags is always a good practice for keeping things organized. Your peers will quickly identify from the name what the feature is about and be able to recognize what areas of the application for which the feature is being used. We won’t take an opinionated view on a specific naming convention; instead, we point out useful examples of naming structures and demonstrate the practical benefits of adopting one.

The feature name example that follows has three parts. First, we present the name of the section the feature is gating. In this example, the feature is gating functionality in the admin section. The second part indicates what the feature does, a self-explanatory naming: make the new invite flow visible to users. And, last, where in the stack the feature is located: here it belongs to the backend layer of the application.

This naming pattern looks like this:

section_featurepurpose_layer

Here’s a specific example that uses the aforementioned template:

admin_panel_new_invite_flow_back_end

Here are a couple of other examples ...