Feature flag usage in a company often begins with a randomly used tool among pockets of developers. When an inflection point is reached and the company decides to make the leap to adopting feature flags as a permanent cornerstone of their software delivery process, the executive sponsors I’ve spoken with tend to all have the same questions. They’ll ask, “If we use feature flags at scale, how will this impact our technical debt over time?” Or, “How do we migrate our old flags into a new system—and what is the time and technology investment required to get a team scaled on using the tool?”
Shortly thereafter, we will typically get questions around visibility and governance: “How can we control who is allowed to update a flag? Who can view a flag but not update it? How can we see the history of a flag? How can our release team or PMs see the status of a flag that a developer updated?”
These are great questions, and ones that every software engineering executive should ask themselves given the power (and potential for chaos) that feature flags hold. What they really want to know is how to get the benefits of feature flags without turning their development organization into the Wild West.
The Wild West: great inspiration for movies and fashion, not so much for development teams
It Starts With Feature Flag Management Visibility and Control
One of the main reasons companies move from no flag management system or a limited “homegrown” feature flag management system is the lack of visibility into flag status and owner. You can’t control what you can’t see. A lack of visibility means potentially only one developer can make a flag update to code because they’re the only one who knows it’s there. Enterprise feature flag management systems all have modern UIs for simple visibility into where each flag is, and who owns it. Feature flag audit logs are a natural extension of this visibility, so that if something does go wrong, you have a breadcrumb trail of who to speak to—or yell at, in some cases.
Audit logs are an easy way to understand what happened if something goes wrong with a flag change.
Visibility is the first step, but control is what truly allows you to scale your feature flag management capabilities across an organization. An environment-based permission model is essential for helping bring more personnel into the process of feature management across development, product, marketing and even sales, but the next step past basic authorization is change approval requests.
CloudBees Feature Management provides the ability for any flag change request to be reviewed and approved before they are implemented. Developers have strict, controlled processes when it comes to code. When source code changes are required, a pull request is opened that is reviewed and then approved or rejected by the authorized party.
The same review process should be applied when it comes to feature flags, in an interface that bridges the gap between technical and non-technical teammates. This capability allows companies that require a higher level of governance to enforce change management policies and to stay compliant with SOC and SOX requirements. Approval requests also provide the ability for read-only users to create a new feature flag for the default audience and submit it for approval. This is possible because flag changes do not go live without approval from an administrator or a colleague with write permissions.
An example of the change approval flow in CloudBees Feature Management
Look at the Bigger Picture of Feature Flag Governance Within Software Delivery
We’ve discussed how to control feature flags within your management tool itself, but what about feature flag governance in relation to the rest of the software delivery lifecycle? While developers would likely be fine updating features in production at any given time, their counterparts on the release or operations teams may not be so thrilled at this ability. To truly scale feature flag usage across software delivery, there must be common views and controls of feature flags across DevOps teams.
DevOps teams can get the benefits of the feature flags with the desired control within release pipelines, as seen here with feature flag visibility in CloudBees platform.
Adding feature flags to continuous delivery (CD) provides a handful of risk mitigation benefits along with the ability to decouple previously monolithic release candidates into feature-level deployments for greater release velocity and consistency. But on some level, feature flags are the antithesis of previously “strong” release governance and compliance policies due to their ability to impact code in production without oversight. That’s why it’s so important to have a tight integration between your feature flag management and your continuous delivery tools, so that feature flag updates do not occur in a vacuum, but instead are visible and controlled across the delivery process.
A view of the software delivery command center within CloudBees platform where you can see all feature flag information within a given release
With Great Power Comes Great Responsibility
Like Spiderman, with great feature flag power comes great responsibility. The ability to change the behavior of an application in run-time without redeploying can completely change the way your company tests and releases software. But it’s also a recipe for disaster if one half of the organization doesn’t know what the other half is doing with feature flags, or if there are users with the ability to update flags without oversight. Feature flag usage cannot occur on an island within the greater software delivery process. A homegrown or even commercial system that isn’t tightly integrated with the rest of the delivery process invites greater risk.