The Future of Feature Flags Lies in Infrastructure As Code

Feature flags are a key component of modern software development and deploying. Having the power to activate or deactivate certain parts of the application at will, without touching the code, will undoubtedly make your software team extremely flexible. Things aren't always a bed of roses though, and that's what today's post is about. We'll start by making a case that feature flags are beneficial, though more often than not, they're done wrong. Then, we proceed to explain some of the existing problems with the usual feature flagging approaches. Finally, we'll present some of the new features in CloudBees Feature Management's upcoming version, explaining how they can help you do a 180 in regards to your feature flagging experience. Let's get started!

On this blog, we talk about feature flags quite a lot. And the reason for that is simple: feature flags are awesome. A feature flag is a powerful tool that can save you from the problems caused by long-lived feature branches, while at the same time providing a similar service. In other words, they allow you to prevent users from accessing uncomplete or unstable features. By employing feature flags along with extremely short-lived topic branches, developers can integrate their work very frequently, avoiding nightmarish scenarios caused by difficult merges. A great feature flag strategy is a must-have for modern software development teams. It's a key enabler of constant, rapid feedback, which is one of the cornerstones of agile software development. Unfortunately, most strategies aren't great.

Yes, feature flags are an awesome tool. But they're a tool nevertheless. They can be misused, abused, or poorly implemented. Sadly, when it comes to feature flags, you often see all three. How do people make these mistakes? What are the main problems with common feature flagging strategies nowadays?

First of all, there's the overly simplistic implementation. Think of this approach as the junior implementation of a feature flag, if you will. It consists of adding if statements to the code that check the values of hard-coded boolean values in order to activate or not activate a given feature. Does that approach work? Well, for a very limited definition of "work," sure. But this solution isn't particularly manageable or scalable. Worse, it robs you of what's probably the main benefit of using feature flags: the ability to alter production behavior without having to edit code and recompile and redeploy the application. To cater to this problem, developers evolve their feature flagging approach to the next level. They move the flags out of the code, usually in the form of config files. This is definitely an improvement over hardcoded boolean valuables. It allows developers to alter the application's behavior in production without changing a single line of code. It also makes it possible to have different flag values for different clients. With the right amount of diligence and creativity, you could even put that flexibility to work in advanced test scenarios. What's the matter, then?

Well, when you really think about it, you'll see that feature flags have some weird characteristics when compared to other software techniques. Let's do a quick thought experiment. Do you use code reviews in your software team? If so, would you commit unreviewed, potentially critical code to production? I hope the answer is "no." Another question: do you use Git? Or any other versioning system? It's overwhelmingly likely the answer is "yes," and I'm well aware of the potential the question has for sounding ridiculous, but I had to do it. So, if you answered "yes," here's the next question: would you allow a piece of critical code in your application to remain completely unversioned? If you've answered "no" to both questions above, then the inevitable next question is this: why do you hold your code to such high standards but don't do the same for your flags? Feature flags change production but don't have to meet the same criteria and demands as other production-changing software. If your feature flags consist of humble text files, directly edited on the servers whenever the need arises, then you have many potential problems to deal with. How do you make people accountable for the changes they do to flags? How can you keep a historical record of said changes? Can you trace any given chance back to its business reasons? Can you be certain a given flag is correct? Feature flags are a weird beast: even though they change production, they don't behave like other software artifacts that do so. They circumvent all processes around changes and traceability. No code reviews. No versioning. Nothing. How to deal with such problems? IaC to the rescue!

The answer to our dilemma lies in infrastructure as code (IaC). Infrastructure as code refers to the technique of managing computer data centers through definition files instead of interactive configuration tools. IaC is a key component of modern software deployment strategies. By keeping infrastructure configuration in code format, you automatically gain many benefits. The main one is probably versioning: code can versioned, diffed, and rolled back at will. Versioning automatically leads to traceability, which is something that was lacking in the more primitive approaches we've covered. By embracing the IaC philosophy, you can take a truly sophisticated approach to feature flagging. When flags management becomes code, things get easier. Code can—and should—be kept in a repository, where it can be read, compared, analyzed at will. And traceability becomes not only possible but virtually inevitable.

The upcoming new CloudBees Feature Management version will bring many new features that will allow you to harness the full power of IaC and put it to work on behalf of your feature flags strategy. Let's see what CloudBees Feature Management's new version will be able to do for you:

• It will represent all experimentation (flag configuration data) and target groups as YAML files locally in a Git repo. At this point, it should go without saying the huge benefits that having configuration data as versioned text files can bring. And that's not to mention that YAML is a solid format choice. It's a lightweight, simple, and human-readable data serialization language.

• It will give the team a CLI that allows them to edit the files. Even though the configuration is done through text files, it doesn't mean that the experience of editing them should be subpar. And that's exactly why CloudBees Feature Management's upcoming version will offer a CLI to allow users to edit the necessary files.

• When you make local changes, there's full traceability and change management (via Git). CloudBees Feature Management will take advantage of Git's characteristics of a decentralized version control system, allowing you to have full traceability and revision history even when working locally.

• When local changes are pushed to the main branch in GitHub, we leverage a GitHub integration (the GitHub app) to send the update config data to CloudBees Feature Management servers where we transform the YAML files to the config files the SDK knows how to read and distribute the config file. On the other hand, as soon as the changes are pushed to the remote repository, a GitHub integration will kick in and deploy the updates to CloudBees Feature Management serves.

• If changes are done via the dashboard, the dashboard acts like a Git client and updates the YAML files on GitHub.

In today's post, we've shown you some of the main problems with the most common approaches to feature flagging. We then proceeded to explain the concept of "infrastructure as code" and how it can be the answer to many of feature flagging problems. Finally, gave you a quick overview of some of CloudBees Feature Management's new features. You've seen how you can use them to harness the full power of IaC. And now, nothing stands in your way—so elevate your feature flagging strategy to the next level.