Feature toggles are one of those concepts that sound simple on the surface but unlock enormous power in practice. In this DevOps Meetup Zurich session, I team up with Ben Rometsch, founder of Flagsmith, to explain the what, why, and how of feature toggles. We cover the foundational concepts of CI/CD that make feature toggles necessary, the difference between deployment and release, and how modern feature flagging platforms enable progressive rollouts, user segmentation, and A/B testing.
The Foundation: CI/CD#
Before we can talk about feature toggles, we need to understand a few fundamentals. Continuous Integration (CI) means that every time you commit code, it gets reintegrated with the rest of the codebase. The CI server builds the code, runs static code analysis, static security analysis, unit tests, and integration tests. The output is a deployable artifact. The most important thing: feedback must reach the developer as fast as possible, within minutes, not hours.
Continuous Delivery builds on top of CI. The deployable artifact gets automatically deployed into a staging environment, a production-like environment, where acceptance testing and exploratory testing can happen. Continuous Deployment goes one step further: the artifact flows automatically through all quality gates into production. Change a line of code, commit it, and it flows all the way to production.
“There is nothing more annoying than committing your code and getting feedback two hours later. By that time, you are working on something completely different.”
The Key Concept: Separating Deployment from Release#
This is the fundamental concept that enables continuous deployment: the separation of deployment and release.
A deployment means bringing the compiled code into production with the feature toggle turned off. A release means switching the feature toggle on, giving users access to the new functionality. By separating these two concepts, you can continuously deploy to production without exposing unfinished features to users.
Dark Launches#
When you deploy code to production with the feature toggle off, you are doing a “dark launch.” The functionality is already in production, but invisible to users. This gives you the opportunity to wire up monitoring, alerting, and verify how the new code interacts with the live system under real load.
The most famous example is Facebook Messenger. A full year before the official release, Facebook Messenger was already in production, hidden behind feature flags. Facebook used that year to connect monitoring, alerting, and observe how the messenger behaved under Facebook’s massive load. When the release day came, they simply flipped the toggle and everything worked.
What Exactly is a Feature Toggle?#
At its core, a feature toggle is nothing more than an if statement: if the flag is true, execute the new code path. If the flag is false, execute the old code path. That is the entire concept.
One important distinction: a feature toggle is not an application configuration. Application configurations are permanent settings of your application. A feature toggle is temporary. It exists only to enable continuous deployment or dark launches. Once the feature is released and stable, you remove the toggle from the code.
“Keep track of your feature toggles. If you don’t, they will spread all over the place, leading to messy code and significant technical debt.”
A word of caution: every feature toggle you add is essentially a test case. If you have too many active toggles, the combinatorial complexity grows quickly. Use them wisely and always clean them up after the feature is released.
Managing Feature Flags at Scale#
For a single toggle, a simple if statement and a wiki page might suffice. But at scale, you need proper tooling. Platforms like Flagsmith, an open-source feature flagging tool, provide dashboards to manage flags across environments, control who sees what, and integrate with analytics providers.
Ben Rometsch demonstrated how Flagsmith works in practice:
- Environment-level flags: Create a flag, enable it in development, keep it off in production. This lets engineers test features in dev while production stays stable.
- User-level overrides: Enable a flag for a specific user in production. This allows an engineer to test the new checkout flow in production while everyone else sees the old one.
- Segment-based rollouts: Define rules based on user traits (age, location, plan type) to control which groups of users see a feature. Want to show the new checkout to users over 40? Create a segment rule.
- Percentage-based rollouts: Roll out a feature to 1% of users first, monitor for issues, then gradually increase to 50% and eventually 100%.
Progressive Enhancement and Resilience#
An important design principle: your application must behave in a sane way even if the feature flagging API is unreachable. This is not because the API goes down, but because users have unreliable networks, weird ad blockers, or just walked into a tunnel. Always design for a default behavior that works without receiving flags from the platform.
From Feature Flags to Experimentation#
Once you have feature flags in place, A/B testing becomes almost free. You can show 50% of users the new checkout flow and 50% the old one, then measure which one performs better. You go from “testing in production as an engineer” to “running an A/B test against the platform” with just a few clicks, and no code changes needed.
“The holy grail is completing the loop: from writing the feature code all the way to generating data about the effectiveness of that feature.”
Key Takeaways#
Separate deployment from release. This is the fundamental concept that enables continuous deployment. Deploy with the toggle off, release by switching it on.
Feature toggles are temporary. They are not application configurations. Remove them once the feature is released and stable.
Dark launches reduce risk. Deploying code to production before releasing it lets you wire up monitoring and verify behavior under real load.
Start simple, grow incrementally. Begin with basic on/off flags. Then move to user-level overrides, segment-based rollouts, and finally A/B testing.
Clean up your toggles. Every unremoved toggle adds complexity and potential technical debt. Track them and remove them consistently.
Design for resilience. Your application must behave correctly even when the feature flag service is unreachable.