Rollout

Rollout allows you to flip features quickly and easily. It relies on distributed erlang and uses LWW-Register and Hybrid-logical clocks to provide maximum availability. Rollout has no dependency on an external service such as redis which means rollout feature flags can be used in the critical path of a request with minimal latency increase.

• Docs.

Installation

def deps do
  [
    {:rollout, "~> 0.2"}
  ]
end

Usage

Rollout provides a simple api for enabling and disabling feature flags across your cluster. A feature flag can be any term.

# Check if a feature is active
Rollout.active?(:blog_post_comments)
# => false

# Activate the feature
Rollout.activate(:blog_post_comments)

# De-activate the feature
Rollout.deactivate(:blog_post_comments)

You can also activate a feature a certain percentage of the time.

Rollout.activate_percentage(:blog_post_comments, 20)

You can run this function on one node in your cluster and the updates will be propogated across the system. This means that updates to feature flags may not be instantaneous across the cluster but under normal conditions should propogate quickly. This is a tradeoff I've made in order to maintain the low latency when checking if a flag is enabled.

How does Rollout work?

Rollout utilizes Groot for replicating flags across your cluster. Please look at the groot docs for implementation details.

Caveats

Rollout relies on your nodes being connected through distributed erlang. If you are running your application on more than one node and you are not clustering than your changes won't propogate. You will need to run the command on all nodes but in practice you'll probably just want to look for an alternative solution.

Flags are not maintained in between node restarts. New nodes added to your cluster will be caught up on the current state. But if you bring up an entirely new cluster your flags will revert to their default states. You can mitigate this problem by setting defaults for each flag in your Application.start/2 callback.

Changes made on one node will take time to replicate to other nodes in the cluster. But, its a safe operation to run the same command on multiple nodes. Feature flags will merge cleanly and always default to the latest change seen.

Should I use this?

If you're already running a clustered application then this should be a reasonable solution if you need feature flags.

Future work

I'd like to implement an alternative storage engine for use in non-clustered environments, preferably using a fast storage engine such as redis. If anyone wants to submit that PR I'd love to take a look at it.