As a solution to this there are approaches like dark-launches and soft roll-outs, but often enough they require code and tool changes that are being delayed until very late. That’s quite a bummer since dark-launching is so helpful in moving fast, from both a technical and a product management point of view.

• Developers are happy when they can get code into Production (“nice, it works, check!”)
• Product Managers are happy when they can get early early feedback, at least from a few select customers (and without having to sacrifice on anything by publicly releasing something unfinished)
• (The right group of) Users are happy if they get early access to features

Sounds like reason enough to stop NOT doing it right away huh?

I was in this very situation on a relatively new project, with a million things to do, and I’ve decided to hack a DIY solution together and see where that gets me. Turns out it only a few lines of actual code and is already much much better than nothing. Here’s the premise:

• I just wanted to be able to hide access to a feature, i.e. hide the link in the nav bar that leads users to it (yeah, I know, but it’s ok in this case, and I bet in a lot of cases it is)
• We’re on Heroku so I thought Heroku config vars would be a great way to control it (no code deploy necessary, but also no overhead with databases and backend access etc., Heroku already provides everything)
• Toggling only on a per-user basis (we were THAT small, yes), no other fanciness like user groups, geographic distribution, load balancing or whatever (yet)

And here’s the code that made it work:

Quick run-down:

• Called the class DarkLaunch, more because I liked the sound of it than of its correctness
• It has this one feature toggle method that can be used to surround links etc. a la “if DarkLaunch.feature_visible(…)”. It returns true whenever a particular user should see the feature in this moment, and false otherwise
• It always returns false if there’s not current_user (since we’re toggling on a per-user basis)
• It always returns true for Development and Test (which leads to other problems but for the moment I liked it to have everything visible on Dev)
• Each feature becomes an identifier (like UPLOAD_PHOTOS) that is used when calling the feature_visible()
• It expects a Heroku config var named FEATURE_UPLOAD_PHOTOS
• This config var is expected to contain a comma-separated list of user IDs to should have access to the feature
• feature_visible returns true if the ID of the given user is in that list
• Or once we’re ready to make a feature public to everybody, we can just set the variable to “PUBLIC”. In that case it always returns true, without checking user IDs anymore
• And otherwise it returns false, blocking the feature for everybody else

Usage is then dead simple, as long as “launching” is as simple as showing something on the UI or hiding it:

It’s a bit of a quick hack, of course, and far from a complete or well-done (or flexible, or …) solution in so many ways. But it was great to see that a few lines of code added so much value to rolling out a feature. Feel free to let me know what you think or if you’re interested in using more of this. And who knows, maybe it becomes a little Gem…