#315 Rollout and Degrade pro
Jan 09, 2012 | 13 minutes | Plugins, Deployment
Learn how to use the Rollout gem to deploy a feature to a select group of users and the Degrade gem to automatically disable it upon failure. Also included is a way of doing this from scratch.
- Download:
- source code
- mp4
- m4v
- webm
- ogv
Hello Ryan,
I want to ask a question about rollout gem. I use cancan gem in my app and it is very successful.
Is this gem like the cancan gem? I don`t really understand rollout gem.
Ryan can correct me if I'm wrong, but CanCan is designed to give permissions to different user groups in your app, where Rollout is to help you slowly roll out features, so at some point 100% of the intended users will be using the feature.
Here is an example
Lets say that GitHub had a cool feature they want to release on the homepage.
Think how many millions of developers are on GitHub and would use the new feature on a homepage right away, and if that feature had a bug, you have millions of issues to fix (caused by this 1 bug).
However, if you rolled out the feature to only 1 persent of the millions of users, you'd limit the bug and any issues that are raised from the bug to only 1 person of millions!.
Also, they could then open the feature to 25% of the users and see how the new feature effects performance. Once they are sure that 25% of traffic has stable performance, they can bump the feature to 50% of the users, and so on.
Thank you Andrew, for this good information.
Is there any way of making this work on Heroku without having to pay for their Redis instances?
You could use their free Redis To Go Addon.
[10:35] You could try using Ryan's source to implement it from scratch. It looks pretty strait forward and will not require the Redis backend.
Hello Ryan,
Murat has a good question above. I have the same question.
Can you please explain when and why would you choose this Gem over a CanCan driven soltuion?
Thanks.
Bharat
The only real benefit over cancan is that rollout allows you to specify % of users that are allowed to use a feature.
Ryan, it is great that you show how to implement the whole thing from scratch. IMHO dependency on Redis and two gems isn't worth the functionality they add.
Custom solution might be easily optimized by using ActiveSupport memoize.
Great episode! Have been programming ruby a long time and never seen those global variables.
I guess we normally use constants in an initializer like ROLLOUT = ...
only difference being your can't edit the constant later I guess.
Anyway, great info - thanks!
I like the custom implementation but it could use some work in regards to the percentage selection.
def match_percentage?(user)
percentage ? user.id % 100 < percentage : true
end
It always will select the same users for tests in the same order.
So if you're running multiple tests you have an almost certain chance the same customers will be in each of the same tests.
It'd be better to just randomly pick users (using the percentage as a means to select them) and then sticky session them some way (perhaps a cookie with which features values you're currently opted into) to keep them in the select group. Then you could analyze the results from the tests independently of each other without having them always intersect.
On top of that if you went with the current approach and tended to have multiple faulty features you're subjecting the same users always to these features. If I was always part of the 1% that has features tested upon it I'd likely be annoyed if most of the rollouts were painful as my perception of the site would be degraded. Having it more random will prevent certain users from being the guinea pigs of the lot.
Just a thought but definitely agree having a custom one may be better than having all the extra dependencies.
May be worth it to eventually build out a gem that handles some intense feature testing (alt controls to stabilize populations, quick reporting, feature value touched to determine whether the feature was touched or not by the user, multiple test features for a test, etc) but that's likely outside the scope of this.
Either way, keep up the good work man, enjoying learning Rails through these casts.
To clarify what I meant by in the same order above.
It always will select the same users for tests in the same order (as you ramp up that is -- so if you always run your tests at 20% the same 20% of your site users will be effected).
Ah one last thing is this sort of implementation requires you to be only testing users. So you wouldn't be able to split run a feature on your homepage across all visitors. That may not matter in most cases since you likely can get a feel if it works from users but, for example, if you wanted to test a new sign up form or sign up text to entice users you'd be out of luck.
You missed the point of the percentages, since you are rolling out a feature you want to set an initial set of users that are allowed to use that feature, then as you see it is working well you would increase the percentage. This way the original users who were included in the feature would not suddenly see it go away, and would be included as you increased the percentage.
Why in god's name do we need to use global variables? How is this an acceptable practice?
I'd love to be convinced that this is a good way to develop.