Managing feature dependencies

Some features only make sense together. Make one require another, and Featurevisor releases them in the right order, evaluated locally with each user's context.

Release one feature after another#

A shop is introducing live chat, and then file upload inside the chat for users who have it. Start with live chat:

features/liveChat.yml

description: Live chat widget
bucketBy: userId
rules:
  - key: everyone
    conditions: '*'
    percentage: 100

Then make file upload require it:

features/chatFileUpload.yml

description: File upload inside chat
bucketBy: userId
conditions:
  - feature: liveChat
rules:
  - key: everyone
    conditions: '*'
    percentage: 100

The application reads file upload as usual, without checking live chat itself:

const context = {
  userId: 'user-4',
}
f.isEnabled('chatFileUpload', context)

File upload is off for anyone without live chat. For the others, it follows its own rules, so you can roll it out gradually inside live chat's audience. It also means one change switches off both: if live chat has to go off, file upload goes with it. Test users on both sides of the requirement. Conditions covers requiring a variation, grouping requirements and requiring a variable's value.

With liveChat on, chatFileUpload follows its own rules and users get it. With liveChat off, chatFileUpload is off for everyone too.

Make one feature give way to another#

To make sure no user gets two features at once, make the second require the first to be off:

features/firstFeature.yml

description: First priority feature
bucketBy: userId
rules:
  - key: everyone
    conditions: '*'
    percentage: 50

features/secondFeature.yml

description: Second priority feature
bucketBy: userId
conditions:
  - feature: firstFeature
    enabled: false
rules:
  - key: everyone
    conditions: '*'
    percentage: 100

First feature	Second feature
Enabled	Disabled
Disabled	Follows its own rules

With these 50% and 100% rollouts, about half the users get each feature, and nobody gets both or neither. With 50% on both, the split is about 50% first, 25% second and 25% neither. This is priority, not equal allocation.

Keep the prerequisite in every datafile

A missing prerequisite satisfies enabled: false. Setting expose: false on firstFeature removes it from datafiles without a lint warning about this relationship, potentially enabling secondFeature for everyone. Keep the prerequisite exposed and test the generated targets. Force or sticky overrides on the dependent feature can bypass its requirements.

Lint rejects circular requirements. Do not make both features require the other to be disabled. For fixed cohorts and holdouts, use Mutually exclusive experiments.

Conditions, for the complete syntax and evaluation rules
What comes along, for how dependencies enter datafiles
Mutually exclusive experiments, for shared cohorts and holdouts

Release one feature after another#

Make one feature give way to another#

Related#