Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Conditionally roll out features with redis.

tag: v0.1.0

Fetching latest commit…

Cannot retrieve the latest commit at this time

README.rdoc

rollout

Conditionally rollout features to certain users with redis.

How it works

Initialize a rollout object. I assign it to a global var.

$redis   = Redis.new
$rollout = Rollout.new(redis)

Check whether a feature is active for a particular user:

$rollout.active?(:chat, User.first) # => true/false

You can activate features using a number of different mechanisms.

Groups

Rollout ships with one group by default: “all”, which does exactly what it sounds like.

You can activate the all group for the chat feature like this:

$rollout.activate_group(:chat, :all)

You might also want to define your own groups. We have one for our caretakers:

$rollout.define_group(:chat) do |user|
  user.caretaker?
end

You can activate multiple groups per feature.

Deactivate groups like this:

$rollout.deactivate_group(:chat, :all)

Specific Users

You might want to let a specific user into a beta test or something. If that user isn't part of an existing group, you can let them in specifically:

$rollout.activate_user(:chat, @user)

Deactivate them like this:

$rollout.deactivate_user(:chat, @user)

User Percentages

If you're rolling out a new feature, you might want to test the waters by slowly letting in a percentage of your users.

$rollout.activate_percentage(:chat, 20)

The algorithm for determining which users get let in is this:

user.id % (100 / percentage) == 0

So, for 20%, it's every 5th user.

Deactivate all percentages like this:

$rollout.deactivate_percentage(:chat)

Feature is broken

Deactivate everybody at once:

$rollout.deactivate_all

For some of our less stable features, we are actually measuring the error rate using redis, and deactivating them automatically when it raises above a certain threshold. It's pretty cool.

Note on Patches/Pull Requests

  • Fork the project.

  • Make your feature addition or bug fix.

  • Add tests for it. This is important so I don't break it in a future version unintentionally.

  • Commit, do not mess with rakefile, version, or history. (if you want to have your own version, that is fine but bump version in a commit by itself I can ignore when I pull)

  • Send me a pull request. Bonus points for topic branches.

Copyright

Copyright © 2010 James Golick, Protose, Inc. See LICENSE for details.

Something went wrong with that request. Please try again.