Introduction to Feature Flags in CD (Continuous Delivery)

Are you having problems realizing the speed and agility promised by continuous delivery (CD)? Does continually delivering new code seem impossible to you? Feature flags might be the tool you’re missing! Without them, implementing CD is difficult. With feature flags, it’s not just easier; it’s better.

In this post, we’ll discuss the problems and risks of CD without feature flags. Then, we’ll discuss how flags make it easier to implement CD. We’ll also cover how you may find yourself considering the next step: continuous deployment. Then we’ll wrap up by going over an example release scenario.

Before we get started, let’s talk about what feature flags are. They’re a tool that gives you a mechanism for enabling or disabling application functionality on the fly, without shipping new code.

This deceptively simple tool allows you to deploy new code to production while limiting its availability or turning it off if it causes problems. This means you can change your code’s behavior without deploying a different version. So your deployments and your business decisions are no longer linked. You can do what’s best for your clients without having to consider the cost of new development, an emergency patch, or the rollback of a new release.

Simply put, continuous delivery (CD) is producing software at speed and in short development cycles. By delivering software quickly, developers see a tight feedback loop, and clients experience a steady stream of improvements.

CD requires code to be ready for release at any time. It also requires automated building, testing, and packaging processes. But continuous delivery is not the same thing as continuous deployment. While continuous delivery means that software is deployable at any time, continuous deployment requires automated deployment.

So it’s safe to say that continuous deployment isn’t possible without continuous delivery. But they’re not the same thing.

CD means moving fast. If you have to slow down to finish a feature or, even worse, reverse a release because of a bug, you’ve lost velocity.

With feature flags, you have more options; if you haven’t finished coding or testing new code yet, you can leave it turned off until it’s ready. If one feature fails in testing, you can still proceed with the rest of the release. Most importantly, you never have to roll back because of a feature with a flag.

Feature flags decouple features from each other. So one feature can’t delay an entire release. They can be addressed on an individual basis. At the same time, you’re able to maintain velocity.

By severing the connections between features, flags provide you with more flexibility in handling a feature once it’s been delivered.

You have a choice on where and how you test it. You can verify some features with unit testing. Others can be tested quickly and effectively by your QA teams in a test environment. But you’re better off testing some features in production. Maybe they’re targeted to a specific client who’ll be the final word on when they’re ready. Or perhaps you just can’t be sure until they’re out in the wild.

With feature flags, you have the flexibility to roll out features to select customers. You can turn them back off when they fail, or you can turn them on for everyone when you’re sure they’re ready. You can even tie them to different service tiers.

CD focuses on delivering code quickly to different environments at scale. Feature flags add in the ability to focus on individual features instead of releases. This means you can spend more time delivering quality to your clients.

This attention can take the shape of a canary release that gradually enables new features via flags instead of staged deployments. Or with feature toggles that set up A/B testing to find out which version your clients prefer.

If you’ve had a taste of what continuous delivery can do for your team, then you’ve probably imagined how robust continuous deployment might be.

But the idea of automatically deploying code as soon as it’s committed still sounds risky. You’re still worried about what might make it through your automated testing, regardless of how robust it is.

Feature flags give you an extra layer of safety. Developers disable incomplete code until it’s ready. You can target new capabilities to environments or customers that are prepared for the risks. And, as we’ve discussed before, you can switch failed experiments off until you have a fix for them. Even if continuous deployment is possible, you’ll have to decide if it’s right for your organization and your users’ preferences. But feature flags provide the safety to make this a viable option.

Let’s wrap up with an overview of what a release looks like with and without feature flags. Let’s imagine a release with a handful of bug fixes and three new features.

The bug fixes included in this release are already on the main code branch. A few of them were already delivered as patches to a few systems, and part of the purpose of this new release is to get everything in production on the same baseline.

But without the ability to toggle a feature on or off, the new features haven’t been delivered yet. They’re on a feature branch or, even worse, not in the code repository yet. Someone needs to merge them into the main branch.

While the development team was working on the new features, a few emergencies came up. That’s where the bug fixes and emergency patches came from. So what was supposed to be a simple merge has evolved into something more complicated than expected. How long will the merge take? How many new problems will it introduce?

Once the development team has pushed and built the new code, the CD pipeline delivers it to the test environments. Even though the bug fixes have already been tested and are in production, the new features are not.

QA immediately finds an issue with one of the features, and development rapidly delivers a fix. But, just as it looks like the release is ready to go, a more serious problem is identified.

Is it time to back out that feature and push ahead with the release? How long will that take? Or is it better to hold off entirely until development can address the issue? What happens if another emergency crops up?

The release has made it to production, and there’s an issue with one of the new features. Is it time to roll back? Or push an emergency fix for the new bug?

Depending on the scope of the problem, when the problem occurs, and the difficulty of the fix, an emergency might be the beginning of another cycle. If development is already working on a feature branch, this fix might turn into a merge headache down the road.

With feature flags, development adds toggles to new features when they start their work. There’s no need for feature branches. So the emergency fixes that cropped up while development was working on these features don’t cause any conflicts. There’s no need for merges. “Releasing” a new feature means turning it on. Features are in turn decoupled from one another at release, meaning a new feature can be turned on in the trunk without affecting the others. This “decoupling” of features creates additional velocity of releases without dependencies.

The new code is built and delivered to the test environment. One feature has an issue, and just like before, development pushes a quick fix.

Then, a problem with a second issue crops up. It’s going to take longer to fix this one. So that feature stays toggled off, and the release proceeds to production.

There’s another path with feature flags. You have the option to test your features in production.

With tools like Cloudbees, you can target specific customers and work with them to verify a new feature, without any impact on the rest of your clients.

You can also use similar targeting capabilities to run A/B tests to find out which version of a product or feature your clients prefer.

Any issues encountered in production look just like testing in production. If one of the new features fails, turn it off and decide how and when to address it. Compared to the “all hands on deck” rollback of a feature, this is a very simple way to release and remove features for development teams.

We compared CD with and without feature flags. Using the examples above, we demonstrated how the ability to turn features on or off decouples them from each other. We illustrated how that makes it easier to keep your delivery pipeline moving. We also saw how feature flags make recovering from the inevitable issues you encounter simpler.

This is the second blog in a series on feature flags in CI/CD. To read the first blog on feature flags in CI, click here.

Want to learn more?

• Download CloudBees Feature Flags Across CI/CD whitepaper and see how easy it is to improve your CI/CD pipeline with CloudBees Feature Management.

Ready to take the next steps?

• Contact us to speak to a Feature Management expert

• Get started today! Sign up for CloudBees Community Edition - Free for up to 15 Users!
  This is the Industry's best value free edition designed for development teams wanting to manage feature flags with a feature rich scalable platform.