Feature F.L.A.G.S

Feature Flags LifeCycle, Administration, Guidance and Strategies

(In collaboration with Noam Steiner)

Feature Flags (FFs) or Feature Toggles, have become a common standard in today’s SaaS world. They offer us the flexibility to gradually roll out features gradually, test the waters and provide valuable capabilities such as kill switches, A/B testing, and individual targeting.

However, on the flip side of all these advantages lies the challenging and intricate process involved in planning, creating, maintaining and cleaning the FFs.

In this article, we will outline our recommended best practices for managing the life-cycle of FFs and share how we effectively stay ahead and maximize the potential of this highly beneficial tool.

Intro to Feature Flags

FFs are basically toggles that indicate whether a flag is On or Off, True or False. This is typically used as a method of selecting a path in the code, similar to the value of an environment variable.

Basic Example:

function logicalFunction(){
 if(checkFlag(‘use-new-logic’) {
   // new logic
 } else {
   // old logic
 }
}

The above function ‘logicalFunction’ is run according to our flag ‘use-new-logic’.

So, what exactly happened here? The function code checked the value of the flag, based on his value, the function will run accordingly.

This will allow us to gradually rollout new features to customers with the ability to use a Kill Switch when needed.

(Note that the exact syntax obviously depends on which FF platform is being used. Some of the more popular ones are LaunchDarkly, Split.IO, Unleash and others. There are also open-source solutions like FeatureHub and others)

Feature Flags Life-Cycle

1. Planning

In the FF lifecycle, it is important for the developers to know whether a feature (it could be a whole feature or just one part of it) should be implemented using an FF and when it is not required.

When should an FF be avoided and not abused:

· When the feature is a role-based feature — use roles/permissions instead.

· When the feature is a configurational-based feature — use environment variables or equivalent.

This means that already in the design stages, this question should be asked and answered:

Do we need a FF for this ? if so, in what cases ?

If the answer to the above question is yes, this information should go into the ticketing system (e.g. JIRA) so that it is an integral part of the feature’s acceptance criteria.

The timing is important because sometimes, generally in complex features, when your code is completed and then you start thinking about the need of a FF, it can cause major code changes that can be avoided beforehand.

It is important to make sure that this initial planning also includes the FF name, type, scope and a clear plan to remove this FF when it is no longer needed.

2. Creating

When creating the FF, consider a few things:

Scope

Scope means the amount and complexity of code which is affected by the FF. We should always strive to keep this to a minimum, allowing for an easy cleanup when the FF is no longer needed.

In big projects or multi-service projects, Scope can determine the services the FF is related to.

Name

The name has to indicate the FF functionality. For example:

WebApp Show Settings Icons

A good practice is to follow a naming convention, such as:

[Scope] [Action]

Key

The FF key is the actual unique identifier for the FF and will usually have a more strict convention - only lower case, no whitespaces or special characters (depends on the FF SaaS). For example:

webapp-show-settings-icons

Notice that it’s basically the same as the name with less formatting:

[scope]-[action]

Description

This is where we can elaborate a bit more that in the FF name. Such as — side effects, purpose, when to remove, etc.

Could be useful in cases where the maintenance is not great and periodic cleanups are done infrequently

Type

This depends on the FF SaaS being used. Some, like LaunchDarkly have a built-in FF type such as ‘Release’ or ‘Kill switch’. In others, it is up to the configuration and usage of the FF.

Code Guideline

It’s very important to create FFs in the code in a way that will be as much decoupled and easy to remove as possible.

Bad Example:

if (bool && checkFlag('use-new-logic')) {
  // do something for bool
  // do something for FF
}

Good Example:

if (bool) {
  // do something for bool
  
  if (checkFlag('use-new-logic')) {
    // do something for FF
  }
}

It’s much easier and clearer to remove the entire FF code block rather figuring out what logic is related to FF and whats not.

3. Maintaining

Feature Flags can easily get out of control, it will lead to a big ‘technical debt’ to your system with many if-else conditions - ‘spaghetti-code’.

Especially in large systems with a high rate of new features and a diverse target audience.

To get a handle on this, we suggest the following ‘PPP’ method:

- Preemptively create a cleanup task

While planning the feature and realizing that an FF will be used, create a task for the cleanup of the FF.

A more advanced approach to complex FFs would be to create a new Pull Request containing the removal of the FF, while the code is still fresh in mind.

- Periodically review the tasks

Periodically (every 1 to 3 months), review all the open FF cleanup tasks and schedule the removal of those that can be removed.

Example of cleanup consideration in a review process:

• Check if the FF returns only true or false without other conditions like specific users — meaning the flag is redundant.
• Consulting the PM if the feature is fully released and the FF can be removed.
• Check FF Evaluation Logs - logs for each time the FF is checked in the code. If no evaluations in the past time, means the FF is probably redundant. (Some FF SaaS support those logs out of the box)

- Proactively Retire Unused Flags

If there are FFs without cleanup tasks (e.g., legacy), add a cleanup task to consider them during the periodic review process.

4. Cleanup

Photo by Towfiqu barbhuiya on Unsplash

Obviously we can’t simply remove the FF from the platform without breaking anything.

FF cleanup needs to be done on both sides: platform and code.

• First, we will remove the FF from the code, and then from the platform.
• After that we can close our cleanup task.

Summary

Feature Flags are a great resource in SaaS development, but managing their life-cycle is a crucial part of it.

Use the above methods in order to keep the FFs under control and your code clean and maintainable.