5 Best Practices for Feature Flagging

  As software teams seek higher agility, the tools and techniques for software development and delivery continue to evolve every year. DevOps and CI/CD practices provide a solid framework that allows teams to release software with increased automation and with less risk. One of the best ways to do this is to incorporate feature flagging into software development practices. In their most basic form, feature flags are “if and else” statements that create a conditional branch into code, which allows developers to restrict some functionality to certain groups of users. If a flag or toggle is switched on, the code is executed; else skipped. However, feature flags can go beyond simple boolean states and could be a complex logical statement, list, array and more.

Teams across the globe use feature flags (also called feature toggles) for reliable releases and experimentation. A major advantage of feature flags is that they provide a granular separation between delivery and release. Teams can carefully roll out features to a limited audience, validate their functionality and performance and gradually release the same features to a bigger audience using blue-green, canary and other phased deployment practices. While there are obvious benefits of using feature flags, they can get increasingly complex and challenging to maintain over time.

While most teams start using feature flags relying on in-house systems, they lack a scalable strategy for managing the feature flags. As more flags are added to the code, the application becomes harder to test, more difficult for team members to understand and more susceptible to errors. At times, testing in production can also leak issues and expose vulnerabilities to the public. This puts extra pressure on teams and can lead to increased test costs. Without the tools necessary to manage feature flags at scale, the costs and risks associated with feature flagging often outweigh its benefits. You can easily avoid such risks following the best practices in feature flag management. Here are the top five ways for managing your feature flags better:

A proper naming convention for feature flags is the first step towards better management. In the absence of a naming convention, it’s possible for team members to confuse the flags or worse, create flags with the same name. If you don’t label your flags carefully, someone in your team could mistakenly trigger these flags, which can lead to severe disruptions in extreme cases. Adopt a naming convention that allows you to get information about the type or the purpose of the changes introduced to a flag. CloudBees Feature Management provides you with a unique approach that enforces name uniqueness under namespaces based on the type system of the programming language you are using

In order to track changes better, consider logging all the changes to a feature flag. If you set up logging, you can track who introduced a change, and at what time. In distributed teams, this can save numerous hours in figuring out who is responsible or has the rights for a particular change. The effects of feature distribution are not restricted to the engineering team, you should log the feature status to your usage analytics, support systems, etc. With CloudBees Feature Management, we have exposed the impression handler to allow you to report to all your different platforms.

Feature flags can be primarily classified into two different types: release flags and business flags. Release flags allow development and operations teams to hide under-development or risky features temporarily, while business toggles are used on features that are stable but have to be hidden or made visible to select audiences only. Managing the two types of flags in different configuration files can help you reduce complexity and streamline support and debugging. We recommend using the CloudBees Feature Management’ label system to classify every flag type.

Putting feature flags in the hands of non-technical users can be a double-edged sword. Use a granular approach to access controls. Different teams should have different levels of visibility and access to environments and flags. For example, you can consider imposing restrictions on temporary logins or those with support credentials.

Over time, feature flags can contribute to code complexity with deprecated branches and features that were never released or were replaced with something else. Current flags can conflict with previous ones. It can be a challenge to identify which flags are required and which ones are redundant or obsolete. One way to figure this out is to see if a feature flag is always on or off; if so, it has served its purpose. You can also define the flag status to help your teams distinguish between short-term and long-term flags. The status field can be dynamically updated after a defined period, allowing your team to identify which flags are safe to remove. To avoid technical debt from building up, you need to carefully manage flags with precise control and visibility into their changes, rollouts and sunsetting. However, with bootstrapped, homegrown systems, all this can be challenging. Enterprise-ready feature flag management systems can make your mission significantly easier.

• Sign up for a free trial of CloudBees CloudBees Feature Management

• Watch this webinar about why CI/CD needs feature flagging

• Learn the difference between progressive delivery and feature flags with Jenkins X and CloudBees CloudBees Feature Management

• Check out this ultimate guide to getting started with feature flags