DEV Community: AvlCodeMonkey

Feature Flags and Continuous Delivery: Ship It Like You Mean It

AvlCodeMonkey — Mon, 17 Aug 2026 19:56:08 +0000

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 many 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. You deploy, and the feature immediately goes live. With feature flags, you can separate them. That's the foundation of continuous delivery:

Deploy constantly. Release deliberately.

The feature flag controls when code goes from deployed to released. As Scott Hanselman puts it, feature flags let you separate deployment from release, giving you the power to experiment and react quickly. That's a pretty useful superpower.

Test in Production (Carefully)

Staging environments are valuable. They're also never quite the same as production. Real traffic patterns. Real data volumes. Real third-party integrations. Staging approximates these things, but it doesn't perfectly replicate them.

Feature flags let you test in production in a controlled way. Enable a new feature for internal users only. Or expose it to a small percentage of real traffic. Then watch what happens.

This isn't the same as shipping broken code to everyone and hoping for the best. It's a deliberate strategy for gathering production signal before committing to a full rollout. Your users become your test environment. Just... carefully.

Instant Rollback Without a Redeployment

Traditional rollbacks require reverting a deployment. That takes time, especially when your deployment pipeline has multiple steps, approvals, and enough YAML to qualify as a cry for help.

With feature flags, rollback is just flipping a switch. If a newly released feature starts causing problems, disable it in seconds. The bad code is still in production, but it's no longer running. You've bought yourself time to investigate and fix the problem without immediately rolling back the entire deployment. Your weekend is now slightly safer.

Trunk-Based Development

Feature flags also make trunk-based development practical. Instead of maintaining long-lived feature branches, developers commit to the main branch frequently — often daily. But what happens when a feature isn't finished?

Hide it behind a flag.

The incomplete code can be merged and deployed without exposing it to users. This means developers can integrate early and often instead of maintaining massive branches that eventually collide in a spectacular merge-conflict apocalypse.

Trunk-based development can:

Reduce merge conflicts
Improve integration quality
Encourage smaller, more frequent deployments
Simplify the delivery pipeline

Feature flags are the mechanism that makes unfinished work safe to deploy.

What This Looks Like in Practice

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

Set up a flag management server so you're not editing appsettings.json in production like an animal.
Write the code. Wrap it in a flag. Merge to main.
Deploy to production with the flag off.
Enable the flag for internal users. Watch your metrics.
Gradually roll it out to a wider audience.
Fully release the feature.
Remove the flag.

Each step is reversible. Each step gives you more confidence. And if something goes wrong at any point, flip the flag and investigate. No emergency redeployment required.

The Point

Feature flags aren't just about turning features on and off. They're a key part of separating deployment from release. That separation gives your team the freedom to:

Deploy frequently
Test changes with real production traffic
Roll out features gradually
Disable broken functionality instantly
Keep incomplete work off long-lived branches
Practice continuous delivery without treating every deployment like a tripwire

The goal isn't to eliminate risk. It's to make the risk manageable.

If you want to manage your feature flags without editing configuration files in production, check out FeatureFlags.app.

Ship constantly. Release deliberately. Sleep soundly.

Feature Flag Pitfalls: How to Turn Your Codebase Into a Haunted House

AvlCodeMonkey — Mon, 17 Aug 2026 19:51:51 +0000

Feature flags are easy to add and hard to remove. That asymmetry is where the trouble starts.

Used properly, feature flags give you safer deployments, gradual rollouts, and emergency kill switches. Used poorly, they turn your codebase into a haunted house full of dead branches nobody dares to touch.

Here are some of the most common ways feature flags go wrong.

Zombie Flags

A zombie flag is a flag that should have been deleted months ago but wasn't.

The feature shipped. The experiment ended. Everyone moved on. But the flag?

Still there.

Nobody remembers what it does, why it exists, or whether removing it will summon Cthulhu.

Zombie flags accumulate over time. Eventually your codebase is full of if statements that will never execute, conditions that are always true, and dead code paths nobody has tested in years.

It's technical debt with extra steps.

The fix

Treat flag cleanup as part of the feature work. When you create a flag, decide when it should go away. Put the removal task in the ticket. Assign an owner. Set a reminder. Do whatever it takes.

Don't let flags outlive their purpose.

Flag Explosion

One flag? Fine.

Ten flags? Manageable.

Fifty flags?

Better start looking for that spreadsheet.

A hundred flags?

Congratulations. You have more feature flags than features.

Flag explosion happens when teams add flags without a policy for removing them. Every new feature gets a flag "just in case," and somehow "just in case" becomes "forever."

Now every deployment requires checking a giant configuration table before you can figure out what users are actually going to see.

The fix

Keep track of:

What each flag does
Who owns it
Why it exists
When it should be removed

If a flag has no owner and no expiration plan, it's already a zombie waiting to happen.

Or, instead of maintaining yet another spreadsheet that everyone forgets exists, use a feature flag management tool that tracks this stuff for you.

Because the spreadsheet you create at 2pm is definitely going to be updated when you're shipping at midnight.

Right?

Testing Complexity

Here's where feature flags get mathematically unpleasant.

Every binary feature flag can double the number of possible states your application can be in.

Two flags?

4 combinations.

Ten flags?

1,024 combinations.

Twenty flags?

1,048,576 combinations.

You probably don't have time to test all of those.

Neither does your QA team.

In practice, not every combination matters. But eventually you'll hit one that does, and you'll probably discover it when a user finds the exact combination you didn't test.

The fix

Minimize the number of active flags.

Retire old flags aggressively.

Don't let temporary rollout flags become permanent application architecture.

The longer a flag sticks around, the more combinations you have to reason about.

Missing Documentation

"What does EnableSuperMode do?"

"No idea. Don't touch it."

This conversation happens at every company that uses feature flags without documenting them. The original developer left. The ticket was closed. The Slack thread disappeared into the void. And now everyone is terrified to remove the flag because nobody knows what happens when you flip it.

Every flag should have:

A name that explains what it does
A description of why it exists
An owner
A plan for when it should be removed

If you can't explain a flag in one sentence, it's probably not ready to ship.

The Bottom Line

Feature flags are powerful. But power comes with responsibility, blah blah blah. The important part is:

Add them intentionally.

Document them thoroughly.

Remove them ruthlessly.

Feature flags should make your codebase easier to operate, not turn it into an archaeological dig.

If you're managing more than a handful of flags, a dedicated flag management tool can help you keep track of what's active, who owns it, and what needs to be cleaned up.

Try FeatureFlags.app and stop letting your feature flags become zombies.

The only good zombie flag is a deleted one.

Feature Flags in the Real World: Use Cases That Won't Get You Fired

AvlCodeMonkey — Mon, 17 Aug 2026 19:48:33 +0000

Why do teams use feature flags?

Because "move fast and break things" is only fun until you break prod.

Feature flags let you move fast and break things slightly less dramatically.

Here’s how real engineering teams actually use them.

Canary Releases

A canary release means you roll out a change to a small percentage of users first—say, 1%—before exposing it to everyone.

If the 1% starts screaming, you flip the flag off and investigate.

If they don't notice anything wrong, you gradually increase the rollout.

The name comes from the old mining practice of bringing a canary into a coal mine to detect toxic gases.

Your early users are the canary.

Hopefully, nothing explodes.

This pattern is especially valuable for high-traffic systems where even a small bug can affect thousands of users. Rolling out slowly gives you real production signal without betting the whole user base on it.

A/B Testing

A/B testing with feature flags means showing two different versions of a feature to different groups of users and measuring which performs better.

Want to know if the green button converts better than the blue one?

Wrap it in a flag, split your traffic, and let the data decide.

The flag controls group assignment. Your analytics platform measures the outcome.

When the experiment concludes, you ship the winner and delete the flag.

Simple in theory.

Slightly painful in practice when the experiment runs for six months and everyone forgets what you were testing.

Kill Switches

Sometimes things go wrong in production.

A third-party API starts returning garbage. A database query locks everything up. A new feature is causing unexplained memory leaks.

You need to turn it off immediately, without rolling back a deployment or waking up the release manager.

That's where kill switches come in.

Kill switches are ops-style feature flags that exist specifically for these moments. They're always off by default and flipped on only in emergencies.

With a kill switch in place, the on-call engineer can disable a problematic feature in seconds rather than scrambling through a deployment pipeline at 2am.

Your future, sleep-deprived self will thank you.

Beta Testing and Early Access

Feature flags let you give specific users early access to new functionality before it's fully released.

Power users. Internal testers. Customers in your beta program.

Basically, anyone you trust to find bugs before the general public does.

This lets you collect real feedback on a real feature without committing to a full release.

If the feedback is bad, disable it for the beta group and go back to the drawing board.

If the feedback is good, roll it out to everyone.

The flag controls access. Your users do the testing.

Managing which users are in the beta group is a lot easier from a web UI than from a config file.

A dedicated flag management tool can handle this without making you write custom targeting logic for every new beta cohort.

Dark Launches

A dark launch means you run new code in production but don't show its output to users.

You're testing performance and correctness under real load without making any user-visible change.

The flag enables the code path. The results go to a log or metrics system instead of the UI.

Dark launches are particularly useful for risky backend changes:

New database queries
Algorithm replacements
Infrastructure migrations
Performance-sensitive changes

You get production-scale validation before committing to the new implementation.

That's a much nicer way to discover that your clever new database query takes 45 seconds than discovering it after you've deployed it to 100% of your users.

The Point

Feature flags aren't just a fancy on/off switch.

They're a way to separate deployment from release and give your team more control over what happens after code reaches production.

Use them for:

Canary releases
A/B testing
Kill switches
Beta and early access
Dark launches
Safer production rollouts

Use feature flags.

Break things more safely.

Look like a genius when nothing goes wrong.

And if you want a simple way to manage your flags without building your own admin UI, check out FeatureFlags.app.

Ship it.

Unlocking the Power of Feature Flags

AvlCodeMonkey — Mon, 17 Aug 2026 19:41:17 +0000

So, you shipped a new feature.

Congrats! 🎉

Now the app's acting weird.

Do you nuke the whole release?

Nah. Enter feature flags.

What Are Feature Flags?

Feature flags (aka feature toggles, aka "please don't break prod") let you flip features on or off without redeploying.

It's like hiding switches all over your codebase, so you can turn stuff on for your favorite users—or just yourself, let's be honest—and turn it off when things inevitably go sideways.

Martin Fowler calls feature flags:

"a powerful technique, allowing teams to modify system behavior without changing code."

Translation: you can break things more safely.

Why Use Feature Flags?

Let's say you want to test a new feature, but only on Dave's machine because he's the only one who reads the docs.

Or maybe you want to roll out a change slowly, just in case it's cursed.

Feature flags let you:

Deploy Safely — Ship code to production while keeping the scary stuff hidden.
A/B Test — Show different features to different users and pretend you're doing science.
Instant Rollback — Flip a switch and pretend nothing ever happened.
Continuous Delivery — Ship all the time and break things less. In theory.

As Scott Hanselman puts it, feature flags let you separate deployment from release, giving you the power to experiment and react quickly.

That's a pretty useful superpower.

How Do Feature Flags Work?

It's just a boolean, folks.

On or off.

Store the flag in your code, a database, or some SaaS. Your application checks the flag before running the relevant code.

You can make it as complicated as you want—user-specific, time-based, or tied to the phase of the moon.

Here's a basic example in C#:

public async Task<IActionResult> Index()
{
    if (await _featureManager.IsEnabledAsync("NewDashboard"))
    {
        return View("NewDashboard");
    }

    return View("OldDashboard");
}

Simple enough.

But if editing appsettings.json every time you want to flip a flag sounds like a bad time, you're not wrong.

A central flag management server with a proper web UI is the better move:

No config file edits
No redeployments
No waiting for CI/CD
Just a switch you can flip from a browser

If you're impatient, FeatureFlags.app is free to try.

The Code Monkey's Caution

With great power comes great spaghetti.

Too many flags and your codebase becomes a haunted house.

Label your flags. Document them. Delete them when you're done.

You won't.

But you should.

Conclusion

Feature flags help you:

Ship safely
Experiment with new functionality
Roll out changes gradually
Turn off broken features without a redeploy
Separate deployment from release

Use them wisely, and maybe you'll survive your next production release.

And if you want a simple way to manage your flags without wrestling with config files, give FeatureFlags.app a try.

Case closed. For now. Go get coffee.

Fear Is the Mind-Killer. Dependencies Are the Build-Killer

AvlCodeMonkey — Tue, 11 Aug 2026 16:02:38 +0000

Remember when adding a package was just:

npm install some-random-thing

What could possibly go wrong? Well... Shai-Hulud happened. The recent Shai-Hulud supply-chain attacks are a particularly nasty reminder that every dependency is an invitation into your build environment. Those attacks compromised legitimate packages and used stolen credentials to spread to other packages.

He Who Controls the Dependencies Controls the Build

Every dependency adds more code to trust, more vulnerabilities to monitor, and more updates to manage. This doesn't mean "never use dependencies" or "always re-invent the wheel". We'd all still be writing our own HTTP clients and arguing about JSON parsers. It means minimize them.

When you do need a dependency, consider who maintains it and how much trust you're giving it. For .NET developers, something like Microsoft's Microsoft.FeatureManagement is a very different proposition from grabbing an obscure package maintained by someone with an unpronounceable alias. Microsoft isn't magically immune to vulnerabilities. No one is. But established vendors with mature security practices, release processes, and large communities can be a more comfortable place to put your trust.

The Spice Must Flow. Your Dependencies Don't Have To

Don't blindly consume latest. Pin dependencies to specific versions. Keep lock files under source control. Update deliberately. Review dependency changes instead of letting the package manager summon whatever happens to be waiting in the desert.

Remove dependencies you don't actually need.
Audit direct and transitive dependencies.
Monitor for known vulnerabilities.
Use trusted package sources.
Verify package provenance and signatures where available.
Keep CI/CD credentials locked down.
Give build processes only the permissions they actually need.
Treat unexpected dependency updates as something worth investigating.

Yes, We're a Dependency Too

FeatureFlags.app is a third-party dependency. We know. The irony is not lost on us. That's why the client library is intentionally small and open source. You can inspect it yourself - FeatureFlags.Client on GitHub.

The goal isn't to eliminate every dependency. The goal is to understand what you're trusting and keep that trust as small as practical.

Walk without rhythm and maybe the worm won't find you.