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…
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
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.
Written by
Related posts
That’s a wrap: GitHub Innovation Graph in 2024
Discover the latest trends and insights on public software development activity on GitHub with the release of Q2 & Q3 2024 data for the Innovation Graph.
Seven years of open source: A more secure and diverse ecosystem
Explore insights into open source community growth, innovation, and inclusivity with an updated survey dataset.
GitHub Availability Report: December 2024
In December, we experienced two incidents that resulted in degraded performance across GitHub services.