How to roll out a feature to only a select few users

Question

A good example of what I'm trying to ask about would be Facebook's new Timeline feature. In the beginning, only a select few were allowed access to timeline. As the feature became more solidified in how it was working and bugs were fixed in it, additional users were allowed access to the feature. At a later date, a large group of users were allowed access to the feature and now, its a general feature to all users. How does a development team manage this type of feature roll out?

I've played with the idea of using configuration settings to selectively control access if something is in testing or in production via a configuration file and conditional if statements in the code. Now while this okay for simple features, I believe that if we tried to implement this in a larger feature set it would become unmanageable.

What would be the best way of managing feature roll outs in this manner?

Answer 1

How does a development team manage this type of feature roll out?

It's an easy guess that a system like Facebook is driven largely by databases. All user data is obviously stored in databases, and that likely includes information about how to render the user's data. It's impossible to know exactly how Facebook's database is set up, but it must be the case that a feature like Timeline is rolled out to users in a gradual way by periodically selecting users in the database, based on some criteria, and changing the value(s) of some field(s).

For example, perhaps they have a field in the user table like timeline_status that has values such as not offered, offered, preview, and public. Based on that alone, Facebook's system could decide how to render the user's info page. The FB team could then try out the Timeline feature by selecting some group of users and changing the value of that field.

In practice, I'm sure it's a little more complicated than that, but the core idea is that a user account is just data, and some of that data can determine which features are available. Rolling out a new feature is then just a matter of updating user records in the database.

Answer 2

... and conditional if statements in the code.

Yeah, that's the wrong way to do it. Whatever feature X is if it's configurable then it must extend or replace something. Do THAT in the code. For instance, the FB thing might have something like so:

class UserPageView;
class HatedTimelineView : UserPageView;
class OldViewEveryoneLikes : UserPageView;

Then you'd build a factory that makes UserPageView objects when visiting a user page based on the configuration. You'd activate that view. No silly branches.

You want to do it this way because if someone is asking you to change it once, they'll ask for it again. Further they'll ask to change another thing. Riddle your architecture with special cases and if's all over the place and you'll have a giant bowl of unmantainable, moldy spaghetti rather than a feature rich, mature product.

Answer 3

Think of the feature the same way you would think of a administration feature on a wedsite.

When a page is loading check if the user has the right privileges for the feature if so load it.

Facebook seems to use a location based approach when rolling out new features. This might be as simple as looking at the users ip address to find their location.