Scaling Feature Flags: Visibility Considerations

This is the fourth and final installment of a blog series that explores what you need to consider when scaling your feature flag management tool. You can catch up by reading the first post on the early stages of feature flag adoption, the second post on infrastructure and the third post on security. In this post, we’ll dig into visibility considerations like cross-team collaboration, flag lifecycles, flag dependencies and insights into CI/CD.

Most developer teams tend to start their journeys with feature flagging on a small scale. When there are just a few individuals or perhaps a small team using feature flags, it’s easy for everyone to see all the information they need to see. Of course, like everything else we’ve discussed in this series so far, problems begin to reveal themselves as soon as you start to standardize for a growing number of use cases.

Feature flags can enable next-level collaboration across teams and functions, but if you don’t evolve your management practices as usage grows, you’ll miss out on those benefits over the long term. Configuration files and database tables are two of the most common ways that teams tend to start managing their feature flags. They start out fairly simple and quickly grow more complex as they’re introduced into more environments with their own dependencies. Configurations become more time-consuming as you introduce them into more sophisticated pipelines. Database tables are similar, only without the necessary deploy step. Whenever you update your flags, whether you’re using config files or database tables, it will create a disconnect among team members.  

As more teams start using feature flags and as complexity increases, that disconnect also grows exponentially. You might not be able to tell who owns what, or how different flags relate to each other. This becomes more troublesome when non-technical users—such as product management, marketing, sales and customer success teams—begin to access your feature flag management tool. These teams are most familiar with what your customers actually need, so it makes sense to give them more say over how features are released to customers. Developers can simply hand over new features to the appropriate team and let them decide when to turn them on—which can’t happen if non-technical teams can’t get into the system. It’s important that all teams have access to a centralized platform so everyone can stay on the same page.

All the relevant people—technical and non-technical—need to be able to see what’s created, understand how their own work fits in and delegate as necessary. When you get feedback and need to make changes quickly, everyone should be able to easily see what’s going on. You may decide to build out this platform yourself, or you may decide to migrate to an external platform—either way, it will help you keep development cycle times low and prevent information silos. 

Most feature flags have an inherent “expiration date” when they stop being useful. As soon as they stop being useful, they should be retired to avoid the buildup of technical debt. 

There are a few different types of feature flags, each with their own lifespans and abilities to be dynamic. Generally, about 60 to 70 percent are release toggles, which are put in place to roll out a new release. These are the flags that enable trunk-based development. These flags have a shorter lifecycle than other types, generally not much longer than a couple of weeks. Once the rollout has taken place and everything is running smoothly, they can be retired. Your feature flag management tool should have a well-defined process to monitor which flags have reached the natural end of their lifecycle and take them out of commission. Otherwise, each unmanaged flag will increase the time and resources taken up in the testing phase.

Release toggles also don’t tend to change values very frequently—in contrast with ops toggles and experiment toggles, which may change values with each request. As usage grows at your organization, the variety and complexity of feature flag types will probably increase as well. No matter how long your feature flags live or how often they change, though, it’s crucial that all teams—technical and non-technical alike—stay aware of each flag’s current phase of life and state of use. A wide range of teams may come to rely on feature flags, from product to customer success to engineering. To connect them all seamlessly, a centralized interface becomes more and more important.

On top of that, as various teams work together, everyone—technical and non-technical—should be able to see and understand what each flag does and how different flags relate to each other. You will need to include labels and descriptions on your flags, and adhere to naming conventions so that everyone understands. When something goes wrong, you will also need to ensure that all teams have a “safe mode” that can be activated. 

Dependencies must be visible across teams. You could, for example, have a multivariate flag that depends on another flag governing an earlier stage. Everyone needs to be able to see all the ways that flags are connected, so you can avoid creating circular dependencies and endless loops. Flag logic and user properties should also be readily available. You will want to ensure that all tech stacks—across all teams—are well-documented and easily visible. 

In CI/CD, code is constantly in motion, flowing in a pipeline from each developer’s desk to production. Feature flags can help you understand what’s working and what’s failing.

The first step is to use your feature flags in testing. Each test is an opportunity to toggle a flag and find unexpected side effects and undesired dependencies—whether it’s in CI time, with automated unit tests and integration tests, or after code transitions to production. Adding feature flags to your CI/CD toolbox can enable A/B experiments, alpha and beta testing and staged rollouts.

Feature flags also give you a new tool for performance testing and reporting. If you need to know how new code will impact performance—even if it’s not a new feature that clients will know about—you can add a flag to find out. You can run your tests based on the state of that toggle, and then use them to evaluate performance reports from clients.

Feature flags and CI/CD make each other better. (In fact, we believe that adding feature flags to CI/CD lays the foundation for the future of software delivery.) As you scale your feature flag management tool, it’s important to make sure the solution you choose can integrate with all parts of your CI/CD toolchain.

If you’ve recently realized that you will need to scale your feature flag management tool, make sure to think through visibility concerns such as:

• How will you ensure that smooth cross-team collaboration can take place?

• Can all teams see each flag’s current phase of life and current value?

• How are flag dependencies communicated?

• Are all tech stacks fully documented?

• Can you use feature flags to pull insights from your CI/CD toolchain?

If you have the resources to scale your own feature flag solution, it’s imperative to consider not only what is the pain point today, but potential use cases that may come up down the line. This will help you determine the architecture you need, and will inform your upgrade strategy for new languages and integrations to come.

But planning for the future is tough, and not every team may be in a state to customize a tool themselves. That’s where external platforms like CloudBees Feature Management come in. Feature Management is an enterprise-ready feature flag management tool that can help you manage, release and measure features at scale. Whether you decide to invest in a homegrown solution or migrate externally, the management and adoption of feature flags at the enterprise level should be made as streamlined as possible so everyone can stay on the same page.

• Read the blog: “Five Ways to Boost Innovation Across the Software Development Lifecycle”

• Download the whitepaper: Feature Flag Management: Should I Build or Buy?

• Find out how CloudBees Feature Management can help your organization by signing up for a free, full-access 14-day trial