What are feature flags, and how to use them? Feature flags for application developers and businesspeople

Now more than ever before, we expect IT systems to be improved in nearly real-time. At the same time, their owners want to easily identify and deliver the best technological solutions possible. The answer may lie in using feature flags as accelerators for application development.

In this article, I will explain what they are and what problems they solve.

And before I jump into the nitty-gritty, let me just add that this is the first post of the feature flag management series.

In my future articles, I will show you how Azure can help us here and what practices I can recommend to you based on my experience with .NET apps.

What are feature flags?

Oftentimes you will also find them under the name ‘feature toggles.’

In short, they can help us with specific features we want to be enabled on demand.

If a feature is not ready yet, it can be disabled in production. This prevents users from taking advantage of offers that still need to be improved.

What is more, if you want to test a feature before going live, you can test it on a small cohort of users and get feedback. Once you have it, you may decide whether it is ready to use by everyone.

Other functionalities include enabling a feature in specific conditions.

For example, when a high load on the system is expected. When properly used, feature toggles might help you save serious money and increase your application user experience.

Feature flags give flexibility to software development teams as they can decide which features are not ready for website users to see. At the same time, that doesn’t stop them from shipping the whole code to production.

As a result, developers will not fall behind, and users will get access only to well-defined, ready features.

Enabled and disabled features in the production stage

Flags allow us to use feature branches. In other words, executing one code branch or another.

That may come in handy when you need to execute an old but stable branch or create a new experimental one.

Depending on the precondition, a feature flag will be enabled or not. Also, you run different code branches for different feature flag values as illustrated in the code sample below.

if (FeatureFlagEnabled("FeatureFlagName"))
{
    ExecuteNewCodeBranch()
}
else
{
    ExecuteOldCodeBranch()
}

The precondition (FeatureFlagEnabled method in the code sample) might be as simple as looking at an application configuration for a Boolean value.

But this could also be something more ambitious such as enabling the flag for a specific user cohort only (e.g., beta-testers).

As a side note, you will find this technique useful when applying the Trunk Based Development to your projects.

Types of feature flags

There are countless applications of feature flags and depending on the business need, you will choose a different flag type.

In total, there are four of them:

1. Release feature flags
2. Experimental feature flags
3. Operational feature flags
4. Customer and permission feature flags

Once we know the basics, let us learn more about their characteristics and benefits.

RELEASE FEATURE FLAGS

These are the most popular among cloud app developers, and usually, Project Owners decide when and how to use them.

While working on a product, they use them to hide specific features when releasing software. Release flags also enable Continuous Delivery (CD) and trunk-based development.

How does that translate into business?

Imagine that you are developing an online shop and you need to prepare a feature for a special offer. In this case, it will be promotion coupons for customers to redeem.

Although it may seem like a no-brainer, the logic is quite complex, and it will take a few days to complete the feature.

How to merge your changes? There are two ways to go:

1. Create a branch where you will store your changes and merge them when the development is ready.
2. Merge your changes as soon as possible to the common branch even if feature-related tasks are not finalized yet. However, be aware that if you insert a promotion coupon, there will be no limitations regarding several usages, and customers may possibly redeem it more than once.

What sets the two approaches apart?

When working with the first one, you receive feedback at the end of the development stage. That can cause additional work which could have been avoided by merging changes more often.

Another drawback is that if your local branch is kept for a long time then syncing it with your master branch can be tricky and can lead to bugs.

As for the second approach, it will not be applicable if customers are allowed to use an unfinished feature at the production stage.

RELEASE FEATURE FLAGS IN PRACTICE

Let’s say that your team frequently releases your software to production. How can you possibly deliver new features?

If unfinished features hold you back and make you postpone production deployment, then you will never be able to deliver anything as there will always be some features in the making.

And here comes the solution – a release flag!

You may simply hide your unprepared feature behind a new flag.

At the same time, in your non-production environments, you could have the flag turned on so that QA engineers and the business team can see the progress and point out potential gaps.

When the feature is disabled on production, customers don’t see it and cannot use it. That way you can also prevent an uncontrolled redemption of promotion coupons.

Promotion coupons are visible by the development team only

EXPERIMENTAL FEATURE FLAGS

Just as release flags, experimental toggles are used most frequently, but not exclusively, at a Project Owner’s request.

Sometimes they will suggest beta-testing the feature first before running it in production to see how it could affect the business.

In other words, although the promotion is ready to use, it is not yet available to customers.

Let’s continue with the previous example.

The situation is as follows: the promotion coupons feature was developed, well-tested, and accepted by the company. However, they are not sure whether the special offer will serve its purpose.

What if the coupons don’t attract any new clients and the shop will only make a loss on the promotion?

With that in mind, the Product Owner wants to test the feature on a small group of beta testers to get the necessary data.

EXPERIMENTAL FEATURE FLAGS IN PRACTICE

To make that possible, you will need to enable experimental toggles. Once you have done that, the system will turn on the feature only for beta testers.

Promotion coupons are available to beta users only

When the company is ready to go ahead with the promotion, you can switch on the toggle and the feature will be available for all users.

Another idea is to run the A/B testing where the development team creates two versions of the same feature for beta testers to check.

Later, the company makes their choice based on beta users’ feedback.

A/B testing with feature flags

OPERATIONAL FEATURE FLAGS

This type of toggles is commonly used by Ops or DevOps teams.

There are situations when some, usually new and noncritical, features have a switch-off function. The team may choose to turn it off on the whole application performance degradation.

What for? Again, let’s use the online shop example.

OPERATIONAL FEATURE FLAGS IN PRACTICE

Imagine that it has a report generator that is causing increased database usage. As a result, the performance of the main application performance drops.

When this happens, the team may switch off the reporting tool when a high load is drawing close.

Another example would be cloud applications with two scaling systems:

1. Standard – used when no high load is expected. It scales the application slowly to save the cloud usage fee.
2. Extreme – used when a company is expecting many clients to use the application at the same time. This scales the app fast and pre-allocates a higher number of resources. Although more expensive, the application can process the load without hiccups.

How does the Ops team know which scaling mechanism to use?

An operational flag will be the answer!

Operational flags for scaling mechanisms

Once the toggle is in place, you will reap the first benefits.

When there are fewer customers visiting the online shop, the standard system will work and the cost for the cloud will be lower.

And when there is a multitude of users, the extreme system will be turned on and there will be no app performance issues, which will only increase the user experience and possible revenue.

CUSTOMER AND PERMISSION FEATURE FLAGS

Now it’s time for the last type of feature flags – customer toggles.

Project Owners and development teams use them to enable features only for specific target groups.

What does that mean?

Suppose that a shop has three types of customers:

1. Ordinary customers – order irregularly,
2. Silver customers – order more than ordinary customers,
3. Golden customers – order in large numbers.

As part of its customer retention strategy, the shop wants to make dedicated offers to golden customers (e.g., special discount, top priority shipping), and silver customers (e.g., free shipping).

To make that happen, you may use customer toggles.

CUSTOMER FEATURE FLAGS IN PRACTICE

This type of toggles will help you modify access and define eligible customer group lists.

Customer feature flags

PERMISSION FEATURE FLAGS IN PRACTICE

Apart from customer flags, you can also choose permission feature flags. They work in a similar way.

The only difference is that instead of different customers with different features enabled there are various roles or permissions assigned to specific features.

Permission feature flags

Summary

If you need a tried-and-tested way to improve your cloud application functionality and user experience, then feature flags are the way to go.

In my next article, I am explaining in detail how you can implement them in a quick and easy way.

And if you need help with creating an app in the cloud or guidance on DevOps practices, do not forget to let us know.

Further reading

Introduction to feature toggles by Martin Fowler

See other articles in the series:

1. How to implement feature flags and filters in .NET apps?
2. How to manage feature flags in ASP.NET Core apps with Azure?