Featurevisor

Feature management

Feature management separates releasing a feature from deploying the code behind it. Teams use it to decide who gets a feature, when, and how it behaves, without a new release. This page explains the vocabulary and how each term maps to Featurevisor.

What teams use it for

  • Release when the business is ready, not when the code ships, as Decoupled releases shows.
  • Give a new feature to a few users first, and widen it as confidence grows, with Progressive delivery.
  • Compare versions of a page with real users in an experiment.
  • Change settings, copy or limits without a release, using remote configuration.
  • Switch something off fast when it misbehaves, with a kill switch.
  • Let customers who opt in try features early, through early access.

Terms

Feature flag

A feature flag decides at runtime whether a user gets a feature. It is also called a feature toggle or a feature switch. The application asks for the flag each time it needs it, so different users can get different answers, and the answer can change without a release. In Featurevisor, a flag is a feature without variations, as Flags shows.

A/B test

An experiment splits users between versions of something, such as a button's text, and compares how each version does against a goal, such as sign ups. When several things change together, such as a headline and a button, it is a multivariate test. In Featurevisor, the versions are a feature's variations.

Remote configuration

Values an application reads at runtime instead of hard coding them, such as the payment methods offered in each market. In Featurevisor they are global variables, or feature variables when they belong to one feature.

Rollout

Making a feature available to users, all at once or in steps. In Featurevisor, each rule of a feature has a percentage, and raising it adds users without removing any.

Canary release

A rollout that starts with a small share of users, so problems show up before they reach everyone. Progressive delivery walks through one.

Dark launch

Code that is live in production but hidden from users, so the team can try it there first. See Testing in production and Trunk based development.

Kill switch

A way to turn a feature, or a whole flow, off for everyone without a release. See Kill switches.

Targeting

The conditions that decide who gets a feature, based on what the application knows about the user, such as their country, plan or device. In Featurevisor, conditions compare attributes from the context your application passes, and segments name reusable audiences, such as Dutch users or paying accounts.

Bucketing

How users are placed in a rollout or a variation, so the same user gets the same answer on every visit and every device that passes the same ID. See Bucketing.

How Featurevisor does it

Featurevisor keeps every definition in a Git repository. A change, such as raising a rollout from 25% to 50%, is a pull request: reviewed, tested in CI and recorded in history. This is the GitOps workflow.

CI builds static JSON datafiles and publishes them to hosting you choose. Applications load them into an SDK, which evaluates locally, with no request per decision and no user data leaving the application. Cloud native architecture explains why that design needs no Featurevisor service.

There is no hosted dashboard for editing. Changes happen in files, Catalog shows the project to people who do not read them, and experiment results come from your own analytics. Alternatives compares this with managed platforms.