How we deploy new features

There’s been some recent discussion about rolling out new features. Ross at Flickr talked about using flags and flippers. Forrst mentioned their use of user buckets.

The nice thing about these techniques is that they’re simple and easy to tweak to meet your specific needs. Before launching Orgs, we relied on user feature flags to determine which users had beta access. However, we didn’t want to worry about enabling Orgs for all of the user’s fellow team members. This lead to a few UI if statements like this:

<% if @user.has_orgs? || @user.organizations.size > 0 -%>
<a href="...">Organizations</a><!-- link to organizations tab -->

<% if @user.has_orgs? || @user.organizations.size > 0 -%>
<a href="...">Organizations</a><!-- link to organizations tab -->

We deploy a lot, but I don’t like littering the commit history with small configuration tweaks.

Replacing the Downloads server recently gave me a chance to try a slightly new technique: Using Redis for configuration management:

def use_nodeload?
  case GitHub::Config[:nodeload]
    when 'public' then current_repository.public?
    when 'all'    then true
    else               false
  end
end

def use_nodeload?
  case GitHub::Config[:nodeload]
    when 'public' then current_repository.public?
    when 'all'    then true
    else               false
  end
end

At one point, I was even sending a percentage of traffic to the new server to see how it handled things. If there were bugs, I could easily tweak the value in Redis without redeploying anything. If we need buckets, we could use Redis’ awesome Set commands.