Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
- Welcome everyone. My name is Rebecca Sliter, and I'm an engineering manager at Kickstarter. Before joining Kickstarter I was a consultant, which meant that I traveled to clients of all shapes and sizes to talk about software development practices. Because of that, I've grown to care a lot about tooling and practices that help teams deliver better code more efficiently.
Over the last few years in particular, I've come to appreciate simple code that can be understood and extended by my teammates. In a nutshell, to me, development should be as simple as possible. I try to stay away from writing clever code, and a lot of my time is actually spent thinking about the best possible way to communicate an idea, domain, or tool across a development team.
Which brings me to the point of my talk. This is "A Tale of Two Feature Flags. " Specifically, what happens when a team implements a bunch of features, puts them behind flags, and ships 'em. Today we'll be thinking about what makes a flag successful and comparing it to other feature flagging strategies that haven't worked out so well.
So let's talk feature flags. This is the opening of the book "A Tale of Two Cities" and I think it really nicely frames what I'm gonna talk about today. Software development, in many senses, has never been so good. Over the last few years in particular we've developed languages, patterns, and release strategies that abstract away a ton of the grunt work and let's us focus on the good stuff.
It really is the best of times. On the other hand though, all of these conventions, patterns, languages, what have you they can be misused. In the wrong hands, the best of times really just means that we can release terrible code faster than ever. And feature flags really exemplify both the best and worst of software development.
They're designed to make our lives easier but often they do anything but. But, I'm getting ahead of myself. Let's focus on the good things for a moment. What exactly is a feature flag and why are they so powerful. Features start off with an idea, right? Everyone's ready to go, jazzed up to build something great and deliver value to real live users.
But then they're hit with a couple of really hard truths. First of all, writing software is hard work. Developing a feature from beginning to end takes a ton of development time. Not to mention, orchestration across the entire team. Ideas take work, turns out.
And once all this hard development work has been done, typically you're sitting there with this big fat DIF's worth of work just sitting there ready to go out and it's really risky to release that. The code's been tested, sure but there are a ton of moving pieces and some small bugs are bound to slip through.
And in thinking critically about this sort of big bang release, you're probably familiar with the type where all of a sudden you ship a ton of code, flip the lights on and everything looks totally different. You realize that you're not sure how this feature is gonna perform with those real live users.
What would be ideal would be to test your idea on a small subset of users and see how they react to it. This is difficult to do though with a gigantic monolithic release. And finally, going back to an earlier point, there are a ton of moving pieces in what you've built beyond the things that you yourself or your teammates have implemented.
Perhaps you're relying on a totally new data store or a third party API. The point is releasing all this at once is risky, especially when you're not sure how your dependencies are gonna scale. And you can communicate this to the business all you want, right? They can have all the grand ideas they want and you get to be the killjoy.
It's really hard, it's a ton of work, I'm not sure how the system is gonna perform with users or with our current infrastructure. And they'll say, "Fine. That's nice. " So, let's go back to my really nice big feature idea. How can we minimize the risk of releasing this grand idea that I have? And we all know that the answer is to put it behind a feature flag.
At a high level, flags are configured in their own files, typically yaml files, where you set the features to on or off. And these files usually start out pretty naively, just a flat file with Boolean values, right? Big feature off, maybe some other features are on, and that's how they're configured.
And then throughout your code base, rather than just implementing the feature, you query that Boolean config value and decide whether the user should see the feature or just the other existing functionality. Depending on the state of the flag, the user will see one of two things.
Either the existing UI plus the brand new feature that's behind the flag turned on or just the plain old UI. It's as if the feature doesn't exist to them. And when you think about it flags solve a lot of the concerns that I mentioned earlier. Well, if something is a lot of work then you can release it iteratively.
[ ... ]
Nota: se han omitido las otras 2.305 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.