Feature Flags: Release Without Redeploying

Deploying code and releasing a feature do not have to be the same moment. Feature flags, also called feature toggles, let you ship code to production with a new feature switched off, then turn it on for a small group, a percentage of users or everyone, without another deployment. Used well, they make releases calmer and rollbacks almost instant. Used carelessly, they leave a codebase full of forgotten switches and confusing paths. This guide explains the main types of feature flags, how to implement them, how to roll out safely and how to keep the number of flags under control.

What feature flags do

At its simplest, a feature flag is a condition in your code that decides which path to run, with the decision controlled by configuration rather than by deploying new code. Martin Fowler's long article on the subject describes feature toggles as a powerful technique that allows teams to modify system behaviour without changing code (Martin Fowler: Feature Toggles).

That separation is what makes flags useful for microservices. A team can deploy its service on its own schedule and coordinate the moment of release separately.

The four types of feature flags

Fowler groups toggles into categories that differ in purpose and lifespan:

• Release toggles let incomplete or untested code paths be shipped to production as latent code that may never be turned on. They support trunk-based development and should be short-lived.
• Experiment toggles support A/B or multivariate tests, consistently sending each user down one path based on the cohort they are in.
• Ops toggles control operational behaviour, such as letting operators disable or degrade a new feature quickly if it causes performance problems. The article notes that some systems keep a small number of long-lived kill switches for degrading non-vital features under unusually high load.
• Permissioning toggles change which features specific users can access, such as early access for selected customers.

Knowing the type helps you decide how long a flag should live and who controls it.

Roll out gradually

Feature flags make progressive delivery possible. A typical rollout for a significant change:

1. Deploy the code with the flag off for everyone.
2. Turn it on for internal users and test in production conditions.
3. Enable it for a small percentage of customers and watch error rates, latency and support tickets.
4. Increase the percentage in steps while signals stay healthy.
5. Enable it for everyone, then remove the flag and the old code path.

If something goes wrong at any step, switch the flag off. That rollback takes effect without a deployment, which is often far faster than reverting code. Our guide to Kubernetes zero downtime deployment covers the deployment side, which flags complement rather than replace.

Make percentage rollouts consistent

When rolling out to a percentage of users, each user should get the same answer every time. Otherwise, someone might see the new feature on one page load and the old one on the next. A common approach is to hash a stable identifier, such as the user ID combined with the flag name, into a number and compare it with the rollout percentage.

Worked example: a simple flag check

The simplified, untested sketch below shows a small Python function that evaluates a flag for a user, supporting an on/off switch, an allow list and a consistent percentage rollout. The flag store is a plain dictionary here; in practice it would be loaded from a configuration service or flag management tool. All names are hypothetical.

# Simplified, untested sketch
import hashlib

FLAGS = {
    "new_checkout": {"enabled": True, "allow": {"user-17"}, "percent": 10},
}

def bucket(user_id, flag_name):
    digest = hashlib.sha256(f"{flag_name}:{user_id}".encode()).hexdigest()
    return int(digest[:8], 16) % 100

def is_enabled(flag_name, user_id):
    flag = FLAGS.get(flag_name)
    if not flag or not flag["enabled"]:
        return False
    if user_id in flag["allow"]:
        return True
    return bucket(user_id, flag_name) < flag["percent"]

Calling is_enabled with the same flag and user always returns the same result while the configuration is unchanged, and raising the percentage only adds users; it does not move existing ones out.

Build or buy flag management

Small teams can start with flags in configuration files or environment variables. As the number of flags and services grows, a flag management tool adds a user interface, audit history, targeting rules and the ability to change flags at runtime. OpenFeature describes itself as an open specification that provides a vendor-agnostic, community-driven API for feature flagging that works with flag management tools (OpenFeature introduction). Coding against a standard API like this makes it easier to change tools later.

Keep flags under control

The biggest risk with feature flags is accumulation. Each flag adds a branch to test and reason about. Fowler's article stresses that teams must be proactive in removing flags that are no longer needed, and mentions teams that add a removal task to the backlog whenever a release toggle is introduced.

Good habits include:

• Give every flag an owner and an expected removal date.
• Record the type of each flag, since release and experiment flags should be short-lived.
• Review flags regularly and remove those fully rolled out or abandoned.
• Remove the dead code path along with the flag.

Flags and data changes

Flags can switch code paths instantly, but data does not switch so easily. If a new feature writes data in a new format, turning the flag off may leave records the old code cannot read. Plan schema changes so that both paths can work with the data during the rollout. Our guide to schema migrations explains how to make database changes that stay compatible across versions.

Decide who can change a flag

A flag that changes production behaviour is a production change. Decide who may switch each type of flag: developers for release flags in test environments, product owners for experiments, on-call engineers for ops toggles. A flag management tool with permissions and an audit history helps here. So does a simple rule that every change to a production flag is recorded with a reason, so that when behaviour changes unexpectedly, someone can see what was switched and when.

Avoid flags inside flags

Nesting one flag's check inside another's makes behaviour hard to predict and test. Where two features interact, decide the combined behaviour explicitly, or release them one after the other.

Test both paths

Every flag doubles the paths through a piece of code. Run automated tests with the flag on and off, at least for flags in active rollout. Include the flag state in logs and error reports, so that when a problem appears you can see immediately whether it is linked to the new path.

Frequently Asked Questions

What are feature flags?

They are switches in code, controlled by configuration, that turn features on or off for some or all users without deploying new code.

What is the difference between deploying and releasing?

Deploying puts code into production. Releasing makes a feature available to users. Feature flags let you deploy first and release later, gradually.

How long should a feature flag stay in the code?

Release and experiment flags should be removed soon after rollout or the experiment ends. A small number of operational kill switches may be kept long term by design.

Do feature flags replace testing?

No. They reduce the impact of problems by limiting exposure and allowing quick rollback, but both code paths still need testing.

Release features without the stress

We help teams introduce feature flags, progressive rollouts and clean-up habits that keep releases safe and code tidy. See our custom app development services, or talk to us about feature flags.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.