Roll back feature configuration with Git

A rollback in Featurevisor is a new release: change the definitions back in Git, check them, and publish the datafiles again. Applications get the correction on their next refresh.

Switch it off first#

When a rollout misbehaves, the quickest fix is to set its rule to 0%. For checkout from the Quick start, that is one line:

# ...
rules:
  - key: netherlands
    conditions: netherlands
    percentage: 100
  - key: everyone
    conditions: "*"
    percentage: 0

Every user keeps the same bucket, so setting it back to 25% later gives the new checkout to exactly the users who had it before.

This leaves Dutch users on the new checkout, since their own rule is untouched. To switch it off for everyone, add a force entry as Flags shows.

Revert the change#

For an ordinary commit containing the unwanted configuration change:

git switch -c revert-checkout-config
git revert <configuration-commit>
npx featurevisor lint
npx featurevisor test
npx featurevisor build

Use the commit you reviewed. If it contains unrelated work, write a narrower correction instead, and take care when reverting a merge commit. Review the diff and merge it the usual way, so Git records both the change and its reversal.

Keep allocation state intact#

State files keep each rule's variation allocation. Reverting a definition never means deleting them or restoring old ones. Let the pipeline build as usual, so allocations stay stable.

Reverting a flag's percentage restores the same audience, as long as its key and bucketBy are unchanged. For a feature with variations, reverting a lowered percentage or a weight change can move users between variations.

Check the outcomes you mean to restore with test specs, including the boundaries of any percentage that changed.

Publish the correction#

Publish every affected environment and target datafile. A merge alone changes nothing for running applications.

Applications that load a complete datafile should replace it with f.setDatafile(datafile, true). The default merge keeps definitions the new datafile leaves out, so it cannot remove a feature the correction deleted.

How quickly the correction lands depends on your cache lifetime and how often applications refresh, as How long a change takes explains. Once it lands, check the revision and a representative evaluation.

Prepare before an incident#

Decide in advance who can approve a rollback out of hours, so a fix does not wait for the usual reviewers. Keep earlier datafiles as your release policy requires, and know which environment each belongs to. Publishing an earlier datafile again can be a deliberate recovery, but check everything in it, not only the flag you are thinking of. Applications that cannot fetch the correction straight away need a plan too. See Offline evaluation.

Related#

• Deployment
• Kill switches, for switching something off before you roll back
• Progressive delivery
• State files