Feature Flags and Continuous Delivery

Continuous delivery means shipping code to production frequently — ideally on every merge to main. Feature flags are what make that possible without turning every deployment into a high-stakes gamble.

The Core Problem: Deployment vs. Release

There’s an important distinction that most teams blur: deploying code and releasing features are not the same thing. Deployment means putting code on a server. Release means making a feature visible to users. In a traditional workflow, these happen together. With feature flags, you can separate them.

This separation is the foundation of continuous delivery. You deploy constantly. You release deliberately. The feature flag controls when code goes from deployed to released.

Scott Hanselman puts it well: “Feature flags let you separate deployment from release, giving you the power to experiment and react quickly.” (hanselman.com)

Test in Production (Carefully)

Staging environments are valuable, but they’re never quite the same as production. Real traffic patterns, real data volumes, real third-party integrations — staging approximates these things but never perfectly replicates them.

Feature flags let you test in production in a controlled way. You can enable a new feature for internal users only, or for a small percentage of real traffic, and watch how it behaves under real conditions before committing to a full rollout. This is not the same as shipping broken code to everyone — it’s a deliberate strategy for gathering production signal before a full release.

Instant Rollback Without a Redeployment

Traditional rollbacks require reverting a deployment. That takes time, especially if your deployment pipeline has multiple steps and approvals. With feature flags, rollback is just flipping a switch.

If a newly-released feature is causing problems, you disable it in seconds. The bad code is still in production, but it’s no longer running. You’ve bought time to investigate and fix the issue without a full incident response. Your weekend is (slightly more) safe.

Trunk-Based Development

Feature flags enable trunk-based development — a practice where all developers commit to the main branch frequently, often daily. Instead of maintaining long-lived feature branches, you integrate early and often and hide incomplete work behind flags.

Trunk-based development reduces merge conflicts, improves integration quality, and makes the continuous delivery pipeline simpler. Feature flags are the mechanism that makes it practical when features aren’t finished yet.

For more, see Microsoft’s Feature Management docs.

What This Looks Like in Practice

With feature flags and continuous delivery working together, your workflow might look like this:

0. Set up a flag management server so you’re not editing appsettings.json in production like an animal.
1. Write the code. Wrap it in a flag. Merge to main.
2. Deploy to production with the flag off.
3. Enable the flag for internal users. Watch metrics.
4. Gradually roll out to a wider audience.
5. Full release. Remove the flag.

Each step is reversible. Each step gives you more confidence. And if anything goes wrong at any step, you flip the flag and go home on time.

Ship constantly. Release deliberately. Sleep soundly.