How we deploy new features

Image of risk danger olson

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 -->

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

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.

Catch early bird pricing for GitHub Satellite

Sync up with us and leading developers from around the world in Berlin, May 22-23, and get €100 off regular-priced tickets until April 11.

Get tickets

Join us at Maintainerati

Calling all maintainers: Unite at Maintainerati, a one-day unconference to gather, present, and discuss the day after GitHub Satellite.