DevOps.js

DevOps.js Conf 2022

<p>Do you want to release your applications more rapidly with lower risk? Feature flags make this possible. This talk will concretely demonstrate that this is possible and easily within your reach.</p><p>  <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a></p>

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 conflicts. Second problem is when you go to deploy, you're going to get all kinds of process questions like 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? Et cetera. 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 to 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 in 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'll call my feature flag emoji, and I will create it, and I'll 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 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, and 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 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 a review, merge it 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. Okay, 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. 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. We can completely validate this at each step of the development process. Every PR I put out, someone can be trying in a 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 I 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 everything 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 in as 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 going to kill this 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 the 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. Thank you.
