Hiya, folks! I’m Heidi, and I’m here to tell you about this cool contest we’re running in the lead-up to our Trajectory conference. Eight weeks to go! For four weeks, we’re going to ask for your stories about using feature flags, testing in production, control points, canary launches, and all the other weird and wonderful ways it’s possible to control how your code acts after it’s been deployed.
Here’s the plan: You write up how you use feature flags to fit the theme of the week, and the entry we think is most interesting/useful/funny/creative will win a free ticket to Trajectory conference April 29 & 30th. And you’ll get some special elite surprise swag.
Lemme give you a quick example:
problem - the why
Here at Gamer Thumb International, we’re interested in testing out different ways to use video games without activating thumb-overuse injuries. We were trying different feedback movements to see if we could induce people to do physical therapy while also fighting virtual goblins. Changing the movements is disruptive to gamers, so we want to make sure it’s perfect before we go live. We couldn’t just test on our lab systems, because there are too many kinds of consoles and we don’t own them all.
solution - the how and what
We decided to invite the people in our “Accessibility Controls” user group to test the new movements, since they have the widest range of controllers across a relatively small number of people. They opted in using a web form, and we added the email address of everyone who opted into a user segment. We used the user segment to deliver email about the test, and also to target a flag that turned on the new movements for their controllers. We also used the segment to fast-track and identify their bug reports and support requests.
why it’s interesting/weird/cool
Putting everyone into a cohort like this created a kind of cohesion we didn’t expect. The users created a group to talk about how they felt about the new controller motions, the hacks and special tricks they used, and what their physical outcomes were. Because the feedback was so valuable to us, when we closed down the testing round, we also sent everyone in the segment a special online badge to indicate that they helped build the product.
Post your answer here on dev.to, using the hashtag #trajectoryconf and #featureflag. We hope to see some out-of-this-world entries, and if you have any questions, let me know! See you online and good luck!
This week, we’re going to talk about Testing in Production. Charity Majors and I keep saying
Everyone tests in production. Some people do it on purpose.
It’s pretty much impossible to replicate the full weirdness, interconnectedness, and user whimsicality of a production environment.
You’d have to pay for extra licenses for test and figure out a way to get sufficiently-weird user data. It’s really hard. But there is a way that you can do testing that doesn’t affect users and still gives you good data. You test in production, you just don’t show it to everyone.
So bring me all your stories about how you’ve proved out concepts in production before general release, how you find and fix errors live and in real-time, but quietly. I’m going to read them all and I’m genuinely looking forward to it.