Introduction to Feature Flags in CI

Continuous integration (CI) and feature flags look like a match made in heaven. Integrating code regularly, combined with the ability to isolate new features and turn them on and off at will, means you can move fast and still manage risk.

But with great power comes great responsibility. Feature flags require careful planning and continuous management, just like your builds do.

In this post, we’ll discuss what CI and feature flags are. Then, we’ll talk about what CI looks like without feature flags, how they can improve it and what you need to know when you add them to the mix.

Feature flags are switches that let you change application behavior without modifying code. They’re tools that enable you to deliver new features to customers quickly, safely and without building or deploying new code.

A feature is a collection of software functionality. It can be as simple as a new value in a display screen or as extensive as an entirely new set of capabilities in a mobile application. A flag is a variable that’s either true or false. Your application code evaluates a banner and decides how to proceed based on its setting.

So, a feature flag is a variable that surrounds a feature and switches it on or off. A feature flag system like CloudBees Feature Management provides a way to manage these flags at scale.

Continuous integration (CI) is integrating your code early and often. Developers push new code to a shared repo, hopefully, several times a day. Each new push is an integration that your automation system builds and tests.

CI offers many benefits. Your developers get feedback on their changes immediately instead of weeks after making them to a private branch and then finally integrating it. You find problems and conflicts early instead of as part of a risky merge that can take days to complete. However, issues are easier to address since you build each change and (hopefully) subject to automated tests right away.

CI works hand in hand with continuous deployment and continuous delivery. When you combine your CI with immediate delivery, your developers enjoy an even shorter feedback cycle. At the same time, you have an application that’s always ready to be delivered to your clients.

CI helps your team move fast. But without feature flags, that speed could become a liability. 

Let’s look at a few reasons why.

There’s no such thing as error-free code. Bugs will make it into your builds and many of them will make it past your testing, too.

So, you’re going to integrate new features, and some of them aren’t going to work. Without feature flags, you have three choices when it’s time to fix them:

    -    Roll back to the previous build

    -    Code and integrate an emergency fix

    -    Leave the broken feature in the wild until it’s fixed in a regular release

How do you avoid the problems outlined above when you don’t have feature flags? One way is to slow down on integrating code. Maybe the developer is waiting for the time to write more unit tests. Or, maybe the risk of releasing the new feature isn’t worth it without adding in a few more. 

So, the feature lives on a branch that isn’t integrated.

In other words, you’ve stopped implementing CI.

If you want to stick with CI, you can try another approach: Verify your features in User Acceptance Testing (UAT). How long does that take? It depends on your features, your users, and your test plans. You may be able to quickly integrate code and deliver it to UAT, but your developers will miss out on getting timely feedback from production.

What happens when a test fails? You have the same three choices as above. Roll the release back, code an emergency fix, or kick the can down the road. Either way, without feature flags, your code spends a lot of time in UAT instead of in front of customers.

Feature flags add a belt and suspenders to your CI. The risks new features add are mitigated with toggles that manage when new code is turned on or off. But that power doesn’t come for free.

Flags are a way to turn a broken feature off. That’s why they exist: to make it easy to enable or disable a block of code. They diminish the risks involved with introducing a new feature into a build. You have a new choice when a feature fails in a build, in testing, or in production. You can turn it off.

But this ability comes with some costs. How long will that feature stay turned off? Have you created a block of dead code as an alternative to an abandoned feature branch? When does a working flag transition into a permanent feature?

This is a common concern with feature flags. They can quickly turn into a way to accumulate technical debt. Without a process for managing a feature flag’s life cycle, they can be a liability. Enterprise feature flag management platforms contain features that help to easily track and manage a flag’s lifecycle, allowing for the benefits of instant feature disabling with less potential for technical debt.

CI works only when developers integrate early and often. Feature flags facilitate this since your default posture can be to keep a feature turned off until it’s complete. The flag replaces feature branches and avoids the large, risky merges caused by delayed integration.

But when exactly is the feature turned on? Is it enabled for the build and disabled for testing? How does a feature deemed ready by a developer become part of a release? Who’s responsible for managing flag values? 

Do you have tools that make it easy to manage them? An enterprise flag management tool will help you manage feature flags. It will provide you with a shared view of flag state across the enterprise, and tools for lifecycle management.  

Your developers are pushing code daily, often two or three times a day. They’re getting valuable feedback, and you’re delivering value at a rapid pace.

But it bears repeating: There’s no such thing as error-free code. What happens when a build fails? What happens when that failure was because of a feature flag setting? How easy is it to toggle the feature and rebuild? How do you know which features to toggle?

Feature flags are a tool for managing complexity, but they come with a cost. They can hide complexity, which isn’t always good. They can also add to it since the features they’re toggling may have interdependencies. The good news here is that enterprise flag management tools make it easy to visualize and work with the dependencies of flags within a build.

When you combine feature flags with CI, your velocity increases. New features can be pushed through the system quickly and sent to the clients that need them on a targeted basis. You can work with a customer to test a new capability that they need or take advantage of a good working relationship and ask a client to work with you on new features.

We’ve talked about what CI and feature flags are. We talked about how, without feature flags, CI can come to a halt when new features become too much of a risk.

Then we showed how adding feature flags to CI can make it easier to manage change. But flags aren’t free. You need to have a plan for how you’re going to manage them and a way to deal with the complexity that new features always add, regardless of how they’re added to your code. An enterprise management system like CloudBees provides you with the tools you need to successfully integrate feature flags with CI.

The following is the first in a series of posts related to feature flags across CI/CD. To learn more about feature flags in CD, read "Introduction to Feature Flags in CD."

Take the next step and request a feature management demo today. We will show you how you can use feature flags to increase your velocity and deliver better code.