Releasing JavaScript Applications Faster with Feature Flags

Welcome to the Releasing React Apps Faster with Feature Flags talk. My name is David Burrows and I'm a software engineer at Split Software. If you're using a normal development process, you're being impeded on at least three fronts.

First of all, when you create a new feature, you probably create a feature branch, which means that as you're adding code, you are also needing to keep your branch up to date with main. This can get pretty tedious, pretty fast by constantly merging main and resolving the conflict.

Second problem is when you go to deploy, you're going to get all kinds of process questions has QA signed off, has all the testing happened, is stage and prod, are they about the same? Are you sure that that's going to be okay, etc. This is because putting something in prod is very high risk. And so there has to be a lot of process to make sure you don't break the business.

Next problem is when something happens, then you need decide what do you do? Do you roll back? Do you roll forward? Do you take the time to fix the bug? Do you not? This is a problem. When there's a problem with prod, you tend to get panicked. So what the traditional process brings you are three problems, tedium, bureaucracy and panic. Feature flags can alleviate or remove all of these problems, and I'm going to walk through that now.

So I've got here a simple application, and I'm going to start adding to it. Now if I'm doing a new feature with feature flags, the first thing I do is not create a new feature branch. Instead, I go create a feature flag. In this case, we want to add a feature to allow people to get a list of emojis. So I will say, I will call my feature flag Emoji, and I will create it. And I will add some rules here, which I will now save. And what this says now is I've got an on version and an off version of this feature flag, and by default, it is off.

Now I can come over to my code. And here, you can see I have added a React component which takes, which creates the feature flag library and puts it in the context. So I can access it anywhere below it in the component tree. I then have my actual component here where I'm going to say, let me get the information about my feature flag, specifically let me get the current treatment for this feature flags. If this treatment is on, then I'm going to show a link to the emoji page and otherwise not. Last thing I'm going to do here is actually add the emoji page to my code. This is an incomplete version of the emoji page. But that's okay. I can now take my change, put up a review, get it approved, merge that directly to main and deploy. Now you might be thinking, wait a minute, what are you doing deploying an incomplete version of your code to prod? That's pretty scary. We're going to get errors from customers.

Are you are you out of your mind? But I can come up here to the application, sign in and I still do not see a link to emojis. This is because remember, by default, the feature flag is off. And I have set my code up to say if the treatment is on, then show this. So I don't show this. This alleviates at least one and a half of the problems we talked about earlier.

First thing is, I don't have to have a feature branch. I can instead make one change on one PR, put up for review, merge you to main and deploy to prod. I do not have a long lasting branch. This will speed up my development time because I'm not trying to keep two branches in parallel.

Second thing is, because all these new changes are behind a feature flag, putting bits into prod is very, very low risk. You need a lot less process, which means you could be going to prod multiple times a day. Ok, but you might be thinking, well, this is great, I'm putting my bits in prod, but so what? Well, part of the so what is we've already mentioned it, we've gotten our process smoothed down some. But there's a benefit beyond that because my release process is no longer either on or off. It can now be highly tailored.

In this case, I'm going to create a rule here which says when the current user ID is David, that is me, then show the on version. So I can come back here to the application, refresh it, sign in as me, and you see I get the emojis. Now it's incomplete, but I can see that. In contrast, if I log in as Emily, Emily doesn't. So now I've gotten another feature I didn't even know I was missing before when I was doing the traditional development, which is I can do testing in prod. By that I don't mean put the feature out and let my customers test it. What I mean is I can put the feature out in the prod environment, and I can test it, my QA team can test it, my automation can test it, my engineering team, my company can test it. I can completely validate this at each step of the development process, every PR I put out, someone can be trying in your prod and making sure it's okay, so that when we eventually get to the point of doing release, we've already been testing this for like the weeks or months it took to build this feature.

So now that I have this, let's go finish this off. I'm now going to take my emoji page, and I'm going to actually instead of having this little simple thing, let's add a full emoji page here, and again, deploy it. Right? So that will take a moment to go. So now you can see that while I'm doing my development, I'm actually building up a much, much higher quality situation, because I'm constantly testing prod, because I am constantly putting stuff into prod and constantly incrementally checking that, it is much, much safer. So when I get to the point of having a release, I can come in here and try it out, and it would say, feature looks good, I can get some emojis. Now we can decide who to release this to beyond the engineering team. I could, for example, decide, let's by default, give this to 50% of the users and 50% not. So I'm going to save this change, come back here.

Now if I log in as Emily, Emily won't see this. If I log, and it's George, however, George does see it. So 50% of the people out there see it, 50% don't. Great. So now I can be doing this gradual release process. Instead of doing 50, I can do 5% or 1%, and I can get feedback. Am I doing something, something unexpected happening? Am I overheating the databases, for example? And I can catch that early in this release process.

So not only am I making the development process faster with higher quality by constantly deploying and testing in prod, but I can also increase the quality by gradually rolling out to my users. Great. So now we decide we're done. Ready to release it. And then we get a call from customer support saying, if you go and do certain things here, it blows up. If I'm doing traditional development process, now I panic, but because I'm using feature flags, I don't panic, I just say, okay, we've got a problem. Let's turn this off. I'm just gonna kill his feature flags, means immediately shut it off. I come back here. If I log in as George, I don't see the new feature. If I log in as me, I don't see the new feature. Notice it took seconds for me to turn this off. I didn't actually have to do a deploy. I just turned the feature off.

This in turn alleviates a third problem, which is panic. With feature flags, big problem in prod is not a culture panic. You just back out the feature flag. That can take seconds, and you're good to then to continue doing testing on your own. Thank you for listening. I hope you found this useful. Try out feature flags. They will change your life.