Feature Flags
Projector is a modern, web based design platform targeted at folks that value great design, but may not have the skills, time or the budget to invest in traditional high end native desktop design apps.
One of the great parts about Projector being web based is it affords us the opportunity to continuously deploy updates and bug fixes with minimal effort on the part of our customers. As great as continuous deploys are, they are not instant and they don’t by themselves allow us to show different versions of the product to different customers.
So why do we care about instant changes to Projector, and why would we want to show different versions of Projector to different customers?
We know our customers need to be able to rely on and trust Projector if they are going to invest their time in us. They need to trust it’s available when they need it. They need to trust their data is safe and secure. And they need to trust that the product and its features will work the way they’ve come to expect. We also know we’re not going to get new features and updates correct out of the gate. There will be bugs. Things that seemed oh so clear to us will end up being confusing or complicated when viewed through the eyes of our customers. In short, making something great takes iteration and time.
We have several complementary strategies when it comes to quality and iteration at Projector. Fundamentally, it starts with our development team. Yes, we write tests. Yes, we use automation. Yes, we pay attention to monitoring and observability. All of these strategies are important, but we believe nothing can replace humans using our software. From our product, design, engineering and quality team members to our alpha and beta test customers willing to live on the edge with us, humans are what make a product great.
So what does all this have to do with feature flags? We use feature flags as a way to instantly and selectively change the behavior of Projector to enable us to get continuous feedback on the quality of our work in progress. Feature flags let us iterate and work in the light of day of our entire team and customer base, rather than off in the dark corner of a lone engineer’s code branch.
Don’t get us wrong, we’re big fans of branching in version control systems. Our engineering team often uses branching, especially for pull requests and code reviews. That said, we use feature flags to help us avoid conflating development team logistics with what code we deploy, and to whom that code impacts.
At Projector, we create a new flag at the start of work on a new feature. Because we deploy new versions of Projector across our staging and production environments many times a day, it’s typical that a brand new feature may end up in a customer’s web browser well before it’s completed. The key to making this practical is that the new (often incomplete) feature is behind a flag that is turned “off” for customers, and often even our own development team!
So what’s the benefit of that? Our unit tests, test automation, and manual QA are all run against features as they are being developed, not in a mad scramble right before the feature is launched and marketed. While we use branching, most work quickly makes its way to our main trunk branch, so our continuous integration is, well, continuous, and we avoid the “merge hell” of multiple large feature branches trying to land at the same time.
Anyone on our development team can open our feature flag dialog from inside Projector itself and instantly toggle on and off features in progress to check out how they are shaping up, how they might impact other work in progress, or how they compare to Projector without that feature enabled. When a feature is getting close, we can flag it on for specific customers. Often customer requests are the impetus behind particular features. Being able to turn on early versions of features for the very customers that inspired their development has been invaluable for helping make features great, not to mention building a fanatical customer base. Once features are complete, in most cases, we remove the flag and make the code permanent. In some cases, it can be helpful operationally to be able to leave “finished” code flagged to provide a level of control for incident response.
LaunchDarkly provides a ton of client and server side SDKs to get your team going in a matter of minutes. At Projector, we integrated our backend with LaunchDarkly, and then leveraged our existing pubsub system to notify browsers about changes to flags. For development team members, we store overrides to flags in the browser’s local storage, allowing a lightweight way to toggle back and forth between flag states without ever leaving Projector. Thanks to the reactive architecture of our client code, flag changes are reflected instantly in the app.
To be sure, flag based development takes some thought and care. Much like architecting and designing code to be testable, code must be architected and designed to be flaggable. We’ve found investing the up front effort to accommodate flagging in the technical design phase pays for itself in spades when it comes to the quality of the end result.
In this post we’ve highlighted some of the most impactful ways we use feature flags at the heart of our development process at Projector, but like that trusty spanner wrench that sometimes serves as a hammer or pry bar, feature flags have become a key member of our problem solving toolbox.
Interested in working on Projector? Get in touch at careers@projector.com.
