Feature flags

A feature flag is a switch allowing to enable / disable application features.

Feature flags allows to separate delivery from activation.

This means that you can deliver an application with disabled features, and activate it only when they are ready. This also means that you can disable problematic features without having to do another delivery.

It's a nice tool for OPS and SRE engineers, but it's also very usefull for developers, since feature flags allow to leverage trunk-based developement, avoiding many merges and late integration issues.

Centralized VS local flags

Feature flag logic can be entirely stored in your application, for instance by storing flag state in some database.

Centralized flag solution (such as Izanami) have some important benefits:

• Flags can be shared accross applications
• All your flags are visible in one place
• Feature flag allows to define custom activation conditions, that can be changed over time without having to deliver your application again
• Managing access and rights only need to be done in one place

However there are no silver bullets, and centralized feature flag solutions are no exceptions:

• Requesting flags states adds some overhead to your application process (this can be mitigated using one of our clients, or by caching flag state)
• If the centralized feature flag solution is down, your application can't access flag state anymore (you may define a default activation strategy for such cases)

Flag types

As we've seen in previous section, feature flags are very versatile. This section presents their main use cases.

Categories are inspired by this great article from Pete Hodgson.

Release flag

Realeases feature flags are used to keep features disabled while they are not ready.

Using this kind of flag is a good stepping stone toward trunk-based developement and CI/CD.

With Izanami, release flags can be achieved using basic flags (simple ON/OFF flags) or release date features.

Ops flag

Ops flag are usually long living flags, that aims to be used when things go wrong.

This could, for instance, be used to disable feature with high performance impact, or to put part of your information system into maintenance state.

Another use for ops feature could be to cut some services during inactivity periods.

With Izanami, you could implement ops flags using basic flags (simple ON/OFF flags) or time/date range features.

Permission flag

Permission features allows to unlock new feature earlier for some users.

It's a good solution for beta features.

Izanami allows to implement permission flags with user list features.

Experiment flag

Experiment flags allows to try some features on a given proportion of your users.

This could be used to test a new idea on a very small portion of your users.

Izanami implement this using percentage feature.