Feature flags (called feature toggles by some) are a software development and delivery technique that allows software teams to enable and disable parts of a codebase at the flip of a switch. Feature flags enable software teams to adopt DevOps practices, in so much as they help increase deployment speeds, system stability, and cross-team collaboration.
As a cultural shift, DevOps is meant to foster collaboration inside organizations, especially between development teams and operations teams. DevOps practices also allow teams to go fast while maintaining product quality and infrastructural reliability. Teams that make good use of feature flagging perform better in all of these areas.
Feature flagging is a software development technique that has been growing and gaining popularity in recent times. However, some development teams still aren’t quite familiar with it.
This post offers an introductory guide on feature flags and explains how feature flagging supports DevOps.
Feature flags 101
What is a feature flag?
“Feature flag” is one of the many names of a powerful software technique. Also known as a feature toggle, feature switch, and feature flipper, this technique allows you to switch some piece of functionality in your app on and off, from outside of the code.
“From outside of the code” is key. Some people might argue that feature flags aren’t really necessary, since you could achieve the same result by commenting out a piece of code and then uncommenting it. That wouldn’t cut it even as a super primitive feature flag approach, though. And here’s why: an essential part of a feature flagging (toggling) strategy relies on being able to activate and deactivate features, in a production environment, without having to change the code and redeploy the application. For example, you can use feature flags as a kill switch to disable buggy code instantly without having to roll back to a previous version of your application.
Feature flags also allow you to decouple code deployments from feature releases. You can make code changes in production while hiding those changes from users.
These abilities are a key facilitator of DevOps. They allow DevOps teams to deploy to production faster, knowing that, in the off-chance the newly developed feature doesn’t work as expected, they can just switch it off, reducing its impact to effectively zero.
In other words: feature flags are a safety net that enables faster code deployments.
How to use feature flags (toggles) to enable DevOps
Continuous Integration/Continuous Delivery (CI/CD)
Feature flagging enables CI/CD, by allowing developers to merge their work into the shared repository frequently, without fear of breaking anything or causing the end user to access unfinished features.
One of the most important ideas in modern software engineering that originated in the agile methodologies is the idea that to go fast, you have to take smaller steps. The classic example of this idea is continuous integration (CI). CI states that all developers should merge their work into the shared repository (e.g., GitHub) at least once a day. Doing so helps prevent nasty conflicts by avoiding long-lived silos of code.
One thing that inevitably happens when a team does continuous integration is that developers will face the conundrum of committing partially complete features to the mainline. If they don’t send their code, they run the risk of having long-lived feature branches that will make merging a pain down the road. However, by merging their code, they might allow the end user to interact with features that aren’t ready to be used just yet.
Feature toggles can come in handy in scenarios like this one. By putting a feature flag around their incomplete feature and keeping it off by default, developers can ship their code without worry. Even if the incomplete feature gets deployed to the end user, they won’t be able to access the functionality. In this way, feature flags enable software teams to do trunk-based development and CI/CD, both key DevOps practices.
When the day comes and the feature is finally ready to go, the flag will only have to be activated and the users will be able to access the feature.
A/B testing
DevOps has its roots in Agile. And the agile methodologies are all about taking tiny steps, getting feedback early and often, and using this feedback to course correct. When it comes to obtaining user feedback, you’d be hard-pressed to find a more effective technique than A/B testing.
With feature flags, you can easily serve different versions of your app for different groups simultaneously, which is pretty much what A/B testing is about. It’s a research technique organizations can use to see how customers react to a new feature or even a new version of an old piece of functionality.
A/B testing consists of splitting your user base into two groups, A and B. Group A is called the treatment. This group of users receives the proposed new version of the app or feature. And group B is called the control. People in it receive the old version of the app or feature. The organization then closely monitors both groups of users to determine which version performs better.
After the experiment is complete, the organization might choose to roll out the new version to the rest of the user base or roll it back.
Testing in production
Feature flags are a powerful enabler of testing in production. The software development technique allows organizations to put features behind a flag but keep them accessible only to selected personnel. That way, the feature can make it to production in a safe way. Available only to authorized people, the feature can be safely tested, with no risk of it being exposed to regular users.
Testing in production—the right way—is vital in many scenarios nowadays. For instance, some types of testing—loading and performance come to mind—require conditions that are hard if not downright impossible to replicate in testing or QA environments. Also, health checks and other types of monitoring can only be done with the “real thing.”
Keep in mind that saying that testing in production is important doesn’t mean you should stop testing before production. Production and non-production testing are complementary, and a solid quality strategy will make use of both.
To truly achieve DevOps, though, you must be able to quickly detect when problems happen in production so you can fix them as quickly as possible, or at least mitigate the damage they cause. And testing in production is a path for achieving those results.
Partial rollouts and canary releases
Canary releases are another technique that feature flags facilitate. They consist of sending a new version of an app or feature only to a subset of users. The DevOps team then closely monitors the release and rolls it back if they detect serious problems. On the other hand, if everything looks fine after some time, the team can roll the release out to the remaining users.
You might be wondering what the differences are between canaries and A/B testing. After all, both of them consist of delivering a different version of the application to a subset of the user base, monitoring it for a while, and then making a decision based on this experiment.
The two approaches differ primarily in regards to their goals. Typically, A/B testing is a market research methodology. You use it when you want to understand how your users/customers will react to a given change. That said, with LaunchDarkly’s feature management platform, you can use feature flags to run experiments and A/B tests on back-end functionality, not just on the front-end, user-facing functionality. A canary release, on the other hand, is a risk mitigation technique. You typically use it when you want to reduce the potential damage caused by a faulty release.
Teams that employ canary tests as a part of their development and delivery processes reduce risk significantly. Consequently, they also provide a better user experience across the board.
How do you implement feature flags?
To implement feature flags, all you need is some way to deactivate and reactivate a piece of functionality that doesn’t require changing the code.
As a primitive approach, you can start by using a config file. The code loads the value of the configuration file to memory and then, based on this value, decides which route to take, using a simple if-then instruction.
This approach might work just fine for basic needs. However, when the number of flags you need to use starts to increase, such a primitive solution likely won’t suffice. That’s when you should start looking for a more sophisticated solution, in the form of specialized feature flag management software or a feature flag service that can, among other things, help you manage all of your flags from a centralized place.
LaunchDarkly is such a solution. LaunchDarkly’s feature management platform enables software teams to use feature flags on a large enterprise scale across a wide range of complex use cases. Teams that employ feature management deploy more frequently and resolve incidents faster than they would otherwise. What’s more, they keep technical debt low.
Feature flags and DevOps: Better together
Feature flagging is an enabler of DevOps. By leveraging feature flags, an organization can make its software development life cycle (SDLC) pipeline faster and more efficient. Iterations become shorter, which avoids conflicts. The organization can deliver value to the customer sooner and more often. A streamlined testing strategy ensures defects are found earlier when they’re cheaper to fix.
In other words, feature flags facilitate virtually everything that the DevOps philosophy stands for: speed, efficiency, quality, and user satisfaction. That’s how the concepts relate to each other, and that’s why your DevOps strategy is incomplete if you don’t leverage feature flags.
***
Learn how to accelerate your DevOps transformation with feature management. Get our free O’Reilly eBook: Effective Feature Management: Releasing and Operating Software in the Age of Continuous Delivery.
.webp)
