Features

In Izanami, feature flags are just called "features" for the sake of simplicity.

Feature activation

Two elements are used to decide if a feature is active:

• Feature status: enabled / disabled
• Feature activation conditions

If a feature is disabled, then this feature is not active, regardless of activation conditions.

If a feature is enabled, activation conditions are used to compute feature activation.

If you just want an on / off feature, don't define any activation condition. In this scenario, feature activation is deduced from feature status (enabled -> active, disabled -> inactive).

A feature can have 0, 1 or more activation conditions, however only one of them need to match to make the whole feature active.

A condition is composed of one time rule and/or one user rule. Possible rules are detailled below.

If both rule are defined, both need to be active to activate condition.

There is a logical "OR" between activation conditions. Inside a condition, there is a logical "AND" between time and user rules.

Feature activation decision tree

Below schema givena an example of feature that define several activation conditions.

Conditions are used here to progressively activate feature for all users, while keeping feature active for two "admin" users: Alice and Bob.

Multi condition feature example

Activation rules

Time rules

With this kind of rules, Izanami will activate feature when current time is in provided range.

These startegies are used to implement release or ops flags.

There is several variation for this catrgory of feature, that can be composed to craft exactly what you need.

• Date range feature: define a start and/or end date for feature activation
• Hour range: feature will be active every day on provided range(s)
• Activation days: feature will be active only on provided days

Here is an example of conditions combination for time features:

• has a date range condition from 1st January to 31 January of 2024
• has two hour ranges: 08h00 -> 10h00 and 14h00 -> 18h00
• has following activation days: monday, tuesday

• ✅ Will be active on Monday 8 January at 9h00
• ❌ Won't be active on Friday 26 January at 9h00
• ❌ Won't be active on Tuesday 16 January at 13h00
• ❌ Won't be active before 1st Januar or after 31 January

User based rules

With user based rules, activation conditions are based on provided user.

Three is two types of user based conditions:

• user list: define a list of user for which feature will be active. This rule is used to implement permission flags.
• percentage: feature will be active only for given percentage of users. Percentage is based on user hash (using murmum3), this means that activation is consistent for a given user (if feature is active once, it'll remain active). This rule is used to implement canary flags.

Scripted feature

Sometimes above rules are not enough. For instance feature activation decision may depend on more than "just" the user.

In such a case, Izanami offers (with the help of WASMO) the possibility to define "script feature".

Such features rely on an underlying wasm script, which will be executed with provided the input each time feature activation is required.

To learn more about these script, refer to the wasm script guides.