What is a Feature Flag Management System?

Software development workflows change over time, and they involve an organized plan of development tasks. Today, these tasks build up the software incrementally. The industry standard for tracking code changes is the source code management tool - Git. But, besides Git, there is another great thing that helps development teams. It is a feature management system. Read on to learn what a Feature Management System is, and its use in software development.

Software Development Workflows

I could divide development workflows into two types. Traditional software development and software development in combination with feature flags.

What is Traditional Software Development?

So, to recap, there is Git. With Git, software source code management is composed of two parts. First, there is a master repository, also known as the main branch, where the production code resides. When working on software, developers create another new sub-branch. This branch is a placeholder to work on a specific coding work. When the work is completed, it is reviewed and merged with the main branch, thus added to production. Or it is rejected for further changes or improvements.

This type of development comes with some advantages and disadvantages.

Advantages:

• Iterative development
• Clean and efficient code
• Traceable and comprehensive code
• Consistent behavior of software

Disadvantages:

• It requires additional effort for developers to test a new branch and make sure it works correctly so that, ideally, there are no or minimal conflicts with the main code.
• There is a waiting period for the developers to finish their parts and assemble the software, which results in slower code deployment.
• There may be a negative customer response, a hidden bug, or an overlooked security vulnerability. To combat this, the developers need to roll back to a previous software version or try a quick fix (which could make the situation worse).

There is an alternative, and that is to implement a Feature Management System.

So what is a Feature Management System?

The feature management system is a programming methodology that helps software engineers create new applications. At its core, it grants additional control over the deployed software. It decouples code release from code deployment. It enables feature flags to turn selected software functions on and off during runtime without needing to deploy new code.

There are two ways to do this:

One way is to develop a feature management solution; this is a very complex process and involves careful design as it has many moving parts. In this case, engineers have a long list of things to do. I'll name a few of them:

• Create the configuration maps, or JSON files, which will be used as a vessel for the flags.
• Create an API system to interact with the flag.
• Use servers or other distribution networks to ship the flag.
• During deployment, engineers control the configuration files manually or create and use a central configuration panel.
• Create and keep track of audit logs, and this would be mostly a combination of the following:
  1. Tracking which flags are in use and identifying unused flags.
  2. Monitoring changes to the flag values and monitoring creation and deletion of flags.
  3. Create an updating algorithm that will keep the flag values up to date in production software.
  4. Create algorithms to balance the distribution of flags to be able to facilitate Canary Releases, Phased Rollouts, User Targeting, and A-B testing.

The second, simpler, and more straightforward way is to use an external feature management service such as ConfigCat. ConfigCat provides everything that is needed right out of the box:

• A central feature management dashboard. To set up and control the flags.
• A Public Management API for those who don't want to work with the dashboard and want to take a programmatic approach.
• Many open-source SDKs to easily implement ConfigCat's flags in different types of applications.
• Easy-to-understand docs on how to integrate flags in many different software environments.
• Tools to facilitate Canary Releases, Phased Rollouts, User Targeting, and A-B testing.

It's good to know that the ConfigCat Feature flags are stored in config.json on the ConfigCat CDN. The ConfigCat SDK downloads and caches the config.json locally in your application. You can set the amount of these downloads from 1 second to several hours. Feature flags are evaluated from the local cache.

With all this said, remember that ConfigCat does most of the heavy lifting behind the scenes. All you have to worry about is:

• setting up the flag and its behavior in the ConfigCat's dashboard or via the ConfigCat's public API
• implementing the SDKs in your software
• wrapping your feature code with the flag

ConfigCat will take care of the rest. So, If you have a dead flag in your application or need to track changes to a flag's value, ConfigCat's Dashboard and audit panel can help. You can also access this information by calling the appropriate API endpoint.

If you need help adding ConfigCat to your software, here are the sample apps to look at how ConfigCat is implemented in different environments. ConfigCat also has a dedicated Community Slack, and you can even book a personal guide on using ConfigCat here.

If you want to know more about ConfigCat's architecture, visit this page.

Scroll to the bottom of ConfigCat's main page to see the entire collection of cards explaining what features ConfigCat provides.

The basics of joining software development with feature flags

Deploying flags is simple.

• First, you create a feature flag in the feature management system.
• Then you import the feature management system into your application.
• Finally, you need to wrap the new code with the feature flag.

import flag from "flag-provider"

if(flag){
  myAwesomeFeature();
}

As you can see from the pseudocode above, the feature is available only if the flag evaluates to true. If it can't, the code will never run. This way, code can be written in the production environment without ever running it.

Feature flags are used to avoid git branching and merging. Then, when the code is ready, or the feature is needed, you just turn the code active by simply toggling the flag from off to on. Finally, when the feature is no longer needed or causing problems, a simple toggle is required to disable the code again.

Look at this article to learn more about decoupling feature releases from deployment.

Benefits of using feature flags:

• Easy to use for A/B testing.
• Easy to target users using segmentation, percentile, or specific user targeting.
• Easy feature control based on its performance.
• Trunk Release - Code can be committed, deployed to production, and later activated.
• Development teams can choose when to deploy new code and to which users.

Feature testing can be done live while gathering feedback from users. When the results are satisfactory, the flag can be removed, and the feature is permanently available to all users.

Disadvantages of using feature flags:

Feature flags are often used outside their original design. They can add interesting and useful functionality because they are very flexible, but using this flexibility comes with increased risk.

I would like to mention some bad developer habits and risks associated with flags.

• Allowing inefficient code instead of improving it
• Leaving bad or dead code instead of cleaning it up
• Not removing old and unnecessary flags.
• Avoiding iterative development
• External sources of truth instead of traceable code
• Hiding functionality behind a feature flag creates confusion about what is running in production
• Testing in production instead of doing proper development testing

What is user segmentation, phased rollouts and A/B testing?

User segmentation is the process of identifying various groups of user data and deducing different characteristics that make each group unique. For example, consider a website that sells women's clothing. The owner wants to increase sales, so she creates three new product sections for her website: a men's, a women's, and a children's. In this case, she has segmented her product according to gender and age to create a more targeted sales strategy.

Phased rollouts make it possible to deploy experiments to a smaller number of users first. It's an excellent way to gradually roll out new feature changes to production. First, testing on low-risk user groups and then gradually increasing the reach of changes to other users.

A/B testing is an experimental design process used to generate data and improve software design or application function. The goal is to determine which version of change is most effective at engaging users. Companies can run A/B tests by changing one variable in their design without affecting the rest of the interface. This allows them to observe which version performs best and make a permanent decision.

These are a few pretty cool uses for a feature flag system. Feature flags can minimize the risk of bad feature releases. This way, companies can control the radius and availability of new features.

Conclusion

Feature management systems are an excellent tool, allowing quicker code releases to production and decoupling feature releases from deployment.

Feature management systems enable companies to introduce new features gradually and decide on the target audience.

Feature management systems help avoid branching and merging. This can save developers from potential merge conflicts by using feature flags to enable features when they are ready.

Feature flags should be treated with respect and care, as they may lead to bad software development practices.

More information on ConfigCat can be found on GitHub, LinkedIn, Facebook, and Twitter.