Lesson 15 of 17
Single Branch with Feature Flags
In this lesson
Roy Osherove presents feature flags (external link, opens in new tab) as what completes continuous delivery (external link, opens in new tab) on a single branch: a configuration setting that enables or disables a partial feature, so its code is deployed to production but not run, and QA can give feedback on it. He recommends keeping development flags and business flags, such as features for customers who pay more, in separate configuration files, and shows examples from libraries such as one for Django and a calculator with an advanced functions feature from an MSDN article. His practices are to remove flags as soon as a feature is done, avoid nested flags, and check a flag only at a single entry point, favoring polymorphism or the strategy pattern over ifs.
Transcript
[00:03] (external link, opens in new tab) Let's talk about feature flags (external link, opens in new tab). The final nail in the coffin to create continuous delivery (external link, opens in new tab) if we want a single branch to me is feature flags. Now the idea is quite simple. Feature flags are kind of a configuration that you can save and they basically tell you if there's a feature that's currently only partial. And this allows you to enable or disable features. So when you start working on a feature here, you create a new flag somewhere in the special configuration and during that time in your code, you will check whether this FA feature is enabled or not and only show the entry points to this feature such as a button or anything like that.
[00:42] (external link, opens in new tab) If the check returns true, if the configuration says it's okay, while when the feature is finally done, destroy the flag so that the feature is always on. This way we have less flags to deal with. So this should be definitely a temporary thing. This way you can develop things in parallel to the main branch but not having a special branch just for it. This way your code is actually deployed to production.
[01:12] (external link, opens in new tab) It's just not being run. And you can also this way expose your code to QA or other types of customers so they can give you feedback on the feature while you develop it. So one of the common uses as I said is to have a partial feature working without needing branching. Another thing that people usually use this for is when they want to enable or disable features for customers who pay more or less. So there's a business side and there's a development side.
[01:44] (external link, opens in new tab) And one of the practices I recommend is to separate. Have these two in different configuration files because if you have everything in the same file, it's going to be very hard to get rid of feature flags that you don't need anymore for delivery purposes and things can get very very hard to maintain and understand. Here are a couple of examples from a couple of libraries for feature flags. Those exist in most of the languages. So for example in the top we can see a Django and how one might check that a switch is active.
[02:16] (external link, opens in new tab) In the bottom we have feature B from C which is an open source project where you can check if a feature is enabled etc. So you can show different messages or anything like that. Here's an example where this is actually from an MSDN article but I find the example very nice to visualize. Let's say you have a calculator. You can have a feature called let's say advanced functions feature that is only visible when the flag is enabled so that customers do not get the advanced features but QA for example might be able to see them.
[02:53] (external link, opens in new tab) So here's a primary list of frameworks that you can find in your favorite language and of course there are more but I'm gathering a whole list of these here in the top at beautifulbuilds.com. So if you want to go to the list or you want to submit your own framework to the list, just head over to that page and there's a link to a form there. Now a few important practices when you work with the feature toggles or feature switches, you have to remove the flags as soon as possible.
[03:25] (external link, opens in new tab) Otherwise, things get very hectic and you don't remember why you have a flag in there in the first place in the configuration file. Don't have nested flags un unless you absolutely have to and usually you don't because nested flags begin to really complicate things and complicate the logic and behavior. So try to do flags in parallel but not nested inside each other. Usually that doesn't make sense in terms of design or the way the people work. So watch out for that. Also try to use flags only at the entry point.
[03:56] (external link, opens in new tab) So don't have like 500 if points inside your code that check that the flag is true or not. Just enable or disable the feature in a single point of entry. Usually that might mean just call a different method on one single class that triggers the whole different process. And this is one good reason why you want to favor polymorphism or if you look up in design patterns the strategy p the strategy pattern over just using ifs because it gives you a very nice design idea of where that single point of entry is.
[04:28] (external link, opens in new tab) Where is where is the exact single place where the whole code goes to a single different kind of parallel universe. If you watch out for these things and you separate the configuration file for business and development purposes, you might actually get away with feature flags in a single branch and your life will be much better.