Feature Flags: Separating Deployment from Release

Deploying code and exposing behavior do not have to happen at the same moment.

A team may place a new search system in production while keeping it hidden, enable it for employees, expand to one percent of customers, and stop the rollout if error rates rise.

A feature flag is a runtime decision that separates putting code into an environment from releasing its behavior to users.

This separation reduces rollout risk, but every flag creates another temporary branch in the system's possible behavior.

A concrete example: gradual search rollout

A company has built a new search-ranking algorithm.

The code is deployed behind a flag. The release sequence is:

1. off for everyone,
2. on for the development team,
3. on for company employees,
4. on for one percent of customers,
5. expanded by region while metrics remain healthy,
6. on for everyone, and
7. old behavior and the flag removed.

Deployment happens once; exposure changes through controlled configuration.

What a flag evaluates

A flag evaluation combines:

• a flag identifier,
• current configuration,
• user or request context,
• targeting rules,
• and a default behavior.

The result may be boolean, but flags can also choose among variants such as old-search, new-search-a, and new-search-b.

Release flags

A release flag hides incomplete or not-yet-approved functionality.

It allows small integration steps to reach the main branch without exposing the entire feature. This can reduce long-lived branches and expose integration problems earlier.

The hidden path still exists in production code and must meet security and operational standards.

Operational flags

An operational flag changes behavior during incidents or load spikes.

Examples include:

• disabling expensive recommendations,
• pausing a background importer,
• switching to a fallback provider,
• or reducing optional work.

These controls need clear ownership, access control, documentation, and regular testing. An emergency switch that no longer works is false reassurance.

Experiment flags

Experiments assign users to variants so teams can compare outcomes.

Correct experimentation requires more than random flag values:

• stable assignment,
• defined success metrics,
• sample-size planning,
• guardrail metrics,
• analysis of bias,
• and a stop decision.

A feature-flag platform can deliver variants, but it does not make the experiment scientifically valid automatically.

Permission flags are dangerous

Feature flags should not replace authorization.

A hidden button is not a security boundary. Attackers may call the underlying endpoint directly. Permission must still be enforced at the protected resource or operation.

Flags control product behavior; authorization controls who is allowed to perform an action.

Server-side and client-side evaluation

Server-side evaluation can keep targeting rules and sensitive attributes away from clients.

Client-side evaluation can make interfaces respond quickly but exposes any configuration delivered to the device. A client flag must never carry secrets or be trusted as the sole enforcement of sensitive behavior.

Sometimes the server decides access and the client flag only controls presentation.

Stable user assignment

Gradual rollout should usually give one user a consistent experience across requests and devices.

Hashing a stable identifier into rollout buckets can maintain assignment as the percentage grows. Random selection on every page load would create confusing switching and contaminate measurements.

Anonymous users require an intentional identifier and privacy-aware persistence strategy.

Defaults and fail behavior

Flag systems can be unavailable.

Each evaluation needs a safe default:

• Should checkout use the proven path?
• Should an optional recommendation disappear?
• Should a security control remain enabled?

The application should not become unusable merely because it cannot contact the flag provider. Local caching and bounded refresh help.

Flag configuration is production change

Changing a flag can alter user behavior immediately without a code deployment.

Therefore flag changes deserve:

• permissions,
• audit logs,
• review for high-impact flags,
• environment separation,
• and rollback procedures.

A convenient dashboard is still an operational control plane.

Testing both paths

While a boolean flag exists, both on and off states may run in production.

Tests should cover:

• each meaningful state,
• transitions between states,
• users with different assignments,
• missing configuration,
• and interactions with other important flags.

The number of combinations grows rapidly, which is one reason flags should not live forever.

Flag interaction

Two independent flags create four possible combinations. Ten booleans create 1,024 theoretical combinations.

Not every combination needs exhaustive testing, but undocumented dependencies create impossible or unsafe states. One flag may require another, or two variants may be mutually exclusive.

Grouping behavior into a well-defined state or variant can be clearer than scattered booleans.

Data and schema compatibility

A rollout may run old and new behavior simultaneously.

Database and message changes must support both paths during that period. Turning a flag off does not help if a destructive migration already removed the data required by the old path.

Rollback capability depends on compatible architecture, not only a toggle.

Observability by variant

Teams need to compare:

• errors,
• latency,
• resource use,
• conversions,
• and user complaints

between flag variants. Without variant labels in metrics and logs, a five-percent failure may disappear inside aggregate success.

Observability is what makes gradual rollout an evidence-based control.

Privacy and targeting

Targeting may use account type, region, device, or behavior.

Only necessary attributes should be sent to a flag service, and sensitive categories require legal and ethical review. Users should not experience unfair or unexplained treatment because a convenient targeting field was available.

Flag evaluation is still data processing.

Kill switches and rollback

A kill switch can quickly stop faulty optional behavior.

It cannot reverse:

• messages already sent,
• money already charged,
• leaked data,
• destructive schema changes,
• or irreversible external actions.

Flags reduce exposure and response time, but they do not replace safe design and incident response.

Flag debt

After a rollout reaches everyone and is proven stable, the flag often has no remaining purpose.

Leaving it behind preserves:

• dead code,
• extra tests,
• confusing configuration,
• obsolete dashboards,
• and uncertain behavior.

Every temporary flag should have an owner, purpose, expected removal condition, and review date.

Removing a flag safely

Removal usually means:

1. choose the permanent behavior,
2. confirm rollout and metrics,
3. update code to use that path directly,
4. delete the old path,
5. remove tests for obsolete behavior,
6. delete configuration, and
7. verify no operational process still uses the flag.

Flag cleanup is part of finishing the feature.

Knowledge check

1. How does a feature flag separate deployment from release?
2. Why must a hidden feature still enforce authorization on the server?
3. Why should rollout assignment be stable?
4. What makes flag configuration an operational production change?
5. Why can a kill switch fail to provide a true rollback?

The one idea to remember

Feature flags let teams deploy code before releasing behavior and expand exposure with evidence. They also multiply runtime states, so defaults, authorization, observability, testing, ownership, and timely removal are essential.