Nano Series Takeaways: “Shipping and Learning Fast via Feature Flags”

71

Leading up to Trajectory LIVE, LaunchDarkly’s two-day conference at the end of August, we’re hosting a Nano Series on the Four Pillars of Feature Management: Build, Operate, Learn, and Empower. Last week we covered the Operate pillar. In this week’s segment, we explored the Learn pillar of feature management.

What is the Learn pillar?

Learn covers feature flag use cases that enable teams to continuously learn from their software and users. In Learn, developers, DevOps engineers, product managers, and others use feature flags for the following:

     

  • Beta groups. Conduct beta tests more seamlessly and gain feedback from real users earlier in the development process.

     

  • Experimentation. Run A/B/n experiments not only for front-end features but also for testing large infrastructure changes, new algorithms, and more.

  •  

  • Baseline metrics and performance tests. Set baseline metrics to compare the performance of one feature variant to another while also measuring the impact of certain features on system performance.

     

Dr. Claire Knight, Senior Engineering Manager at GitHub, walked us through some of the core ideas of Learn in her talk on “Shipping and Learning Fast via Feature Flags”. Here’s the recording:

Takeaways

     

  • Test your feature with the right users. Doing a canary release to a small set of users is a great way to get early feedback, especially if you watch how they’re actually using it. But if the feature is aimed at a particular use case, then that small set of users should be the ones who have that use case. Sometimes you can find that set of users within your organization, and sometimes you need to identify them within your customer base. If your users explicitly opt-in to beta features, they’ll be more willing to put up with bugs.
  •  

  • Test for scale: Claire talked about the variety of methods that GitHub uses to verify that a new feature won’t stress their infrastructure. The earlier you identify potential performance spikes, the better. GitHub engineers will sometimes multiply the internal load from a new feature, or replicate it to multiple endpoints so that they can observe its effect. This concept is known as traffic shadowing. If infrastructure modifications are needed, they’ll also use flags to prepare for migrations.
  •  

  • Super Minimal Ships: You need to stay agile – that’s “agile” with both a small and big A – when developing while testing. If the feedback shows that major changes are needed, you need to get those changes out as fast as possible. But long-lived feature branches create friction. So, instead of keeping new code in a feature branch, GitHub keeps it behind a flag. When developing new features, the first pull request is just to set up a “skeleton”: it creates the space in the code where the feature will go, gated by a flag set to “off”. This means that future development of the feature can be merged to the main branch of the code immediately without fear of breaking the rest of the app.
  •  

  • Watch out for complexity: Claire closed with a vital warning: you still need to move with care. While flags can greatly improve both the speed and safety of releases, they also add complexity and technical debt. While flags are in use, ensure that all the execution paths in your code have test coverage. Tidy up each flag as soon as you no longer need it. In other words, pay attention to the whole feature flag lifecycle.
  •  

  • No, GitHub doesn’t use LaunchDarkly: Like some other other huge, engineering focused companies we could name, GitHub incorporated feature flagging into its development processes before LaunchDarkly was founded. One of their engineers created a Rails gem for feature flagging called flipper. Over the years, flipper was extensively expanded and is deeply woven into their codebase. If LaunchDarkly had been available for GitHub’s use back in 2012, it would have saved them a huge amount of time and money. “Seriously consider other options than ‘build your own’ if that’s not your core thing,” said Claire. We strongly agree.

Conclusion

A big thank you to Dr. Claire Knight for joining us and helping educate us on GitHub’s journey through Feature Flags.

Next week, the Nano Series will cover Empower, the fourth Pillar of Feature Management. Sheree Lim, Product Manager at Tray.io, will touch on some of the core concepts of Empowerment in her talk “Empowering better Feature Management at Tray.io”.

Tune in Wednesday, August 19th at 10 a.m. PT for the last nano series before Trajectory LIVE! Register now.

Yoz Grahame
Yoz Grahame is a Developer Advocate for LaunchDarkly because he wants software engineering to be far less painful than it is now. Previous involvements include: the US Government (in the 18F group), Compaas, Linden Lab, British e-democracy projects WriteToThem and TheyWorkForYou, and Douglas Adams’ startup The Digital Village. On the amateur wrestling circuit he goes by the alias “Dr. Henry Metzger.”