Feature Flags
Feature flags are runtime controls that select which behavior a deployed application uses. They let you release a change to chosen users, limit exposure, or disable behavior without deploying new code.
itDevOps and software delivery | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic - Feature Flags
Feature Flags is the subject of this course. A deployment puts code into an environment. A release exposes behavior to users.
The useful unit of work is a closed loop: clarify the goal and boundaries, gather the inputs the practice requires, make the decision or change, record evidence, and return with owners for the next cycle. Skipping any link leaves teams busy without durable results.
Tooling supports the loop; it does not replace it. Choose tools after the boundary and evidence model are clear. Comparing products without that model produces feature matrices that do not change how the work runs.
Common failure modes include undefined ownership, metrics that count activity instead of outcomes, and irreversible steps taken without a review path. Treat those as design defects in the practice, not as individual heroics to compensate later.
Operators should be able to explain which signals would change a decision this week. If no signal can change the plan, the practice has become ritual. Keep the feedback path short enough that evidence still influences the next cycle.
Name the owners for each stage of the loop before the work scales. Unowned stages become permanent exceptions. Record decisions with enough context that a future operator can tell why a tradeoff was accepted. Prefer fewer, sharper metrics that change behavior over broad dashboards that only describe activity after the fact.
Read the Intro for the core model. Use the Cheatsheet when you need the operating map. Updates tracks official guidance when this course configures an update source; otherwise the practice is settled without a live feed.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://openfeature.dev/
Supports
- Feature flags as runtime controls that enable, disable, or change behavior
- OpenFeature as a vendor-neutral feature flagging specification
- https://openfeature.dev/specification/glossary/
Supports
- Feature flag, evaluation, evaluation context, targeting, targeting key, rule, and variant definitions
- Fractional evaluation using a context property
- Client-side and server-side SDK paradigms
- https://openfeature.dev/specification/sections/flag-evaluation/
Supports
- Developer-facing evaluation API
- Typed values, required defaults, optional evaluation context, and resolution details
- https://openfeature.dev/specification/sections/providers/
Supports
- Provider as the adapter between evaluation calls and a flag management system
- Providers wrapping SDKs, REST clients, or runtime configuration
- Default values and typed resolution methods
- https://openfeature.dev/docs/reference/concepts/provider/
Supports
- Provider abstraction and replacement without major application refactoring
- Default return behavior when no provider is configured or evaluation errors occur
- https://martinfowler.com/articles/feature-toggles.html
Supports
- Runtime behavior changes without a code deployment
- Release, experiment, operational, and permission toggle categories
- Separation of evaluation points from routing decision logic
- Testing complexity, configuration visibility, placement choices, and carrying cost
- Need to constrain and remove temporary toggles
- https://learn.microsoft.com/en-us/devops/operate/progressive-experimentation-feature-flags
Supports
- Separation of deployment from feature exposure
- Runtime exposure to an individual, group, or all users without redeployment
- Use of flags beyond user-interface changes
- https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/approaches/deployment-configuration
Supports
- Progressive exposure by tenant or user without redeploying
- Separation of feature rollout from license entitlement enforcement
- Temporary flags instead of specialized tenant deployments
- https://docs.aws.amazon.com/prescriptive-guidance/latest/micro-frontends-aws/feature-flags.html
Supports
- Coordination of independently released components
- Centralized decisions driving application behavior
- Testing cost, troubleshooting complexity, bundle growth, and technical debt
- https://docs.getunleash.io/guides/feature-flag-best-practices
Supports
- Runtime control, short-lived flags, unique names, and local evaluation
- Server-side evaluation for sensitive context and client-side result delivery
- Cached configuration, availability choices, monitoring, and cleanup
- https://docs.getunleash.io/guides/manage-feature-flags-in-code
Supports
- Centralized keys and narrow SDK abstraction
- One evaluation per request and propagation of the result
- Testing both branches and removal after full rollout
- https://docs.getunleash.io/concepts/feature-flags
Supports
- Environment-specific activation strategies and variants
- Release, experiment, operational, kill-switch, permission, and sunset purposes
- Define, Develop, Production, Cleanup, and Archived lifecycle
- Naming, stale-state, and archival behavior
- https://github.com/sindresorhus/awesome
Supports
- Discovery of the Awesome Developer-First list
- https://github.com/agamm/awesome-developer-first
Supports
- Dedicated Feature Flags section
- Discovery of Unleash, Flagsmith, and ConfigCat
- https://docs.flagsmith.com/managing-flags/core-management
Supports
- Boolean and multivariate feature management
- Per-environment values, segment overrides, server-side restrictions, and archival
- https://configcat.com/docs/targeting/targeting-overview/
Supports
- Targeting rules, user objects, percentage options, and fallback values
- Phased rollout and stable audience selection concepts
