Enterprise Requirements for Managing Feature Flags

The process of feature flagging is fairly straightforward: you wrap your features in conditionals that determine who can see your features and when. At an enterprise scale, organizations must confront the complexities of mitigating technical debt, managing developer workflows, compliance, and controlling the lifecycle of feature flags. To meet these challenges, companies construct or adopt enterprise-grade feature flag platforms built specifically for development teams.

Feature Flag Lifecycle Management

A feature flag is a powerful tool, but with that power comes great responsibility. A feature flag’s lifecycle includes its progression through multiple development stages: local, QA, staging, and production. These phases require extensive lifecycle management where developers can manage the flag’s creation, changes, requests, rollouts, and sunseting.

Typically, home-grown feature flagging systems provide a minimum viable level of functionality for lifecycle management. In other words, these systems enable features to be toggled on or off, but they do not have extensive support for audit logging, change tracking, or team access controls.

This leads to the accrual of technical debt, which refers to feature flag implementation that seems quick and easy in the short-term (i.e using a config file), but may cause more long-term problems if not maintained or scaled correctly. Feature flags become technical debt due to complications with:

• Flag Implementation & Consistency – Feature flags need to be carefully crafted and consistently implemented within your application to prevent performance degradation and ensure that they function correctly. Often times, organizations will use conflicting methods like managing multiple config files or using in-line toggling.
• Flag Scalability – Adding more feature flags makes testing and management exponentially more difficult over time. It becomes very hard to tell which flags are necessary or obsolete.
• Flag Management – Maintaining feature flags across multiple development environments (local, QA, staging, production) becomes arduous and time-consuming. It becomes increasingly difficult to track who created the flag, the flag’s intended use, and changes made to the flag’s rollout.

As more flags are added, application testing becomes harder and more expensive. Technical debt festers over time, where it leads to development, performance, and scalability issues.

Sometimes, time constraints and resource limitations force developers to implement code quickly without proper due diligence. While this is a natural byproduct of software development, it is something that can be mitigated by appending a user interface and developer collaboration suite to your feature flagging system.

Feature Flag Statuses

Think of a feature flag status as a way to display rich data about your flag and provide real-time updates regarding your flag's state (active, inactive, new).

These flag statuses allow teams to manage both short and long-term flags, and know when flags are safe to remove.  Statuses can show you when the flag was added, when it was last requested, the current state of the flag, and the rollout percentage. This gives teams full visibility into their feature flag lifecycles, the ability to clean up flags that are obsolete, and know which features are rolled out.

Here is an example of status implementation:

Audit Log & Access Controls

Foundational to effective feature flag management is the ability to track changes and control access to feature flags.  Teams should construct an audit log that contains a record of all changes made to each feature flag, including who made those changes and when.
The audit log is also critical for organizations that have compliance obligations, giving managers full visibility into the who, what, and when of feature flag changes.

Team Management

When implemented at scale, feature flags become instrumental to a company’s development workflow. Feature flagging is a team effort and often requires coordination amongst diverse teams, like engineering, QA, and marketing.  This substantiates the need for custom development environments and access controls.

Cross Functional Team Support

With cross-functional team support, you should be able to create teams, manage member roles, and customize permissions.  This enables your team to coordinate your workflow around a central point.

At an enterprise level, managers could create different teams to oversee targeted organizational goals, like conversion rates, performance management, and sales metrics.

Other use cases include:

• Marketing teams harnessing A/B testing data to increase conversions
• Design teams testing usability and experimenting with new features
• DevOps teams managing application performance
• Engineering teams decoupling feature rollouts from code deployments

Development Environments

Effective feature flagging teams should have custom development environments for local, staging, QA, and production (with no limit on the number of environments). This enables developers to manage features across multiple testing environments and manage developer access to those environments.

Access Controls

Adding customizable access controls will allow your team to manage permissions for everything in your system, from feature flags to A/B testing metrics.  Managers can assign one or multiple custom roles to each team member using a policy system modeled after AWS.

A few powerful examples of access controls include the ability to:

• Lock your production environment down to a small set of trusted users
• Distinguish infrastructure-level feature flags (controlled by your DevOps team) from experiments (controlled by product management or marketing)
• Allow QA members to control feature flags on designated QA environments only

Analytics & Extensibility

A powerful benefit of feature flags is the ability to assess feature performance and get genuine user feedback from customers.  Organizations will typically already harness a suite of analytics and feedback tools, like MixPanel, Segment, Slack, HipChat, and New Relic.  For a feature flagging system to provide analytical value, it must be able to integrate with these existing tools and allow for customized integrations tailored for an organization’s evolving needs.

Platform Analytics & API

In addition to advanced feature flag controls, your platform could provide integrated support for A/B testing, performance monitoring, or harness an API for your own custom integrations.

Polyglot Language Support

It is not uncommon for organizations to maintain a stack that utilizes multiple development languages and frameworks.  Your platform should be able to support an evolving polyglot stack, both in terms of language composition and mobile/web support.

Summary

An enterprise feature flagging platform should act as a powerful control center, where teams can easily integrate feature flags into their short and long-term development cycles.  If your team is considering building or buying a feature flagging solution, this article analyzes the benefits and costs of a managed feature flagging system versus a home-grown platform.