feature flagging

What is feature flagging?

Feature flagging is a simple programming design pattern that allows developers to turn application features on or off without having to redeploy or change code already in production. Wrapping code with feature flags allows developers to decouple feature rollout from code deployment. A feature flag is also called a feature toggle, feature switch or feature flipper.

Feature flags can be implemented in projects related to infrastructure, back-end or front-end programming and are often used to quickly deliver new functionality to users. Rather than include a new feature in a full version release, feature flagging allows developers to expose a feature to a subset of users to better understand how it will interact with existing features. This facilitates a faster software release with less risk.

How feature flagging works

Feature flagging changes the runtime behavior of an application based on how it is configured. Once a feature is flagged in the code, an administrator can use several methods to determine which users see the feature. Feature flags can be configured in a variety of ways, such as by:

• user attributes, such as geographic location, name and membership level;
• environment, such as machines and IP address;
• random, such as a set percentage of all users; and
• variants of behavior, such as social media activity.

Some feature flags are designed to be short-term, such as those used to roll out new features. Others are meant to stay around long-term, such as for licensing and pricing. Finally, some are considered mid-term flags, such as those used for the long-term development of a new feature.

Development of feature flags

When starting to integrate feature flags into the development process, several factors must be considered. First, identify the current obstacles or points of pain. What repeated issues are arising? Then, recognize the use cases for feature flags in your system. Assess the different uses of the flags, who are the stakeholders -- besides the developers -- and how might a team collaborate to make feature flagging successful?

Next, decide whether to build or buy the feature flag tools. A plan should be created, unknowns prepared for and resources distributed. Compliance and total cost of ownership should be considered as well as the amount of programming languages the flags can handle. Many companies use various libraries in their stacks and continue to adopt new ones as they grow and develop. Therefore, an adaptive feature flagging system that can run with different languages without hindering performance and stability is required.

Once the decision to build or buy has been made, the development team can then coordinate workflow and implement the feature flagging system. It is important for the team to collaborate throughout the flagging process, provide feedback, and manage a full release lifecycle.

Feature flags are useful and inexpensive to create, so they often multiply quickly when first introduced to a system. However, they do create burdens as well. Feature flagging introduces conditional logic and new abstractions to the code and they create a large testing burden. Therefore, to keep the number of flags manageable, the team must proactively remove flags that are no longer needed.

Management of feature flags

Since numerous feature flags are usually in place at the same time, a large volume of flags can result in increased traffic, and make code harder to test, maintain, support and secure. Organizations should create a feature flagging plan that defines:

• responsibilities of managing flag creation, changes, requests, rollouts and deletion;
• flag naming conventions, which should describe what the flag is intended to do so that flags are easily understood and identifiable for future developers; and
• important processes, such as a test-first requirement to assure that every flag is turned on only for the developer or administrator before it is turned on for any other user.

In addition, any system using feature flags should reveal the current state of the flag configuration. Inserting build/version number into a deployed artifact and exposing metadata allows a tester or developer to find out what code is running in a specific environment.

It is also important to manage each flag differently. The various types of flags possess different characteristics and these should be appreciated. While they might be controlled using the same technology, each flag acts differently. These variations should dictate how the flags are managed.

Feature management platforms, also called feature flag management systems, are software and service solutions designed to help developers organize and streamline feature flag configurations and management. These tools are designed to help decrease Technical debt. Most feature management platforms include flag change alerts, simplified rollout management, KPI monitoring and kill switch capability. Some feature management platforms are open source, while others charge a monthly subscription fee, fees based on the number of users who hit a feature flag or fees based on the number of internal users who manage the feature flag Dashboard.

Some open source feature flag management platforms are only compatible with one or two programming languages, while paid feature management products offer support for a wider range of languages.

Implementations and advantages of feature flagging

Feature flagging creates many advantages for developers through the various ways in which it is implemented. Flagging uses include:

• Control of feature releases. A developer can merge, test and deploy code into production and deliver to users as ready.
• A/B testing. An administrator can place users into specific groups and decide at runtime which path each user group will follow. A/B testing is used to assess new features with smaller sets of customers.
• Management of seasonal/temporary features. Developers can enable a feature during certain periods of time, such as holidays or busy seasons, or disable features with heavy processing needs during known high traffic periods.
• Blocking users. Feature flags can be used to restrict or provide specific groups of users with access to certain elements of a website. This is useful for companies who follow regulations that differ by state or country, such as liquor or drug retailers.
• Subscription. Controlling the content and features available to subscribers vs. nonsubscribers is made easier by bundling features with feature flags.
• Kill switch. Feature flagging creates a kill switch which allows companies to quickly turn off a feature if it is performing poorly. This can be combined with percentage rollouts that enable developers to limit the amount of users who receive the active content. If something goes wrong in the initial deployment, then the feature can be immediately switched off and it will have only affected the smallest possible audience.

Canary release

Percentage rollouts are also used in canary releases. A canary release is a test that is used to analyze how a software update might impact user behavior. This is done by creating a canary cohort, or small group pulled from the user base. The cohort is produced from a random sampling of 1% of all users. This group will constantly have the new feature turned on while the other 99% will continue using the old algorithm.

During the test, essential business metrics -- such as gross revenue and user engagement -- are monitored for both the cohort and 99%. Once the development team is confident that the new feature will not negatively impact user behavior, they can adjust their configuration to turn it on for all users.