--- title: "Single Branch with Feature Flags" url: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/single-branch-with-feature-flags.md" canonical: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/single-branch-with-feature-flags/" tags: [] author: "Roy Osherove" description: "Lesson 15 of 17 in Beautiful Builds and Continuous Delivery Patterns (Branching Patterns for Continuous Delivery), 4:50. Free video by Roy Osherove." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Single Branch with Feature Flags 1. [Courses](https://courses.osherove.com/#courses) 2. [Beautiful Builds and Continuous Delivery Patterns](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/) 3. Branching Patterns for Continuous Delivery Lesson 15 of 17 Duration: 4:50 [Watch on YouTube](https://www.youtube.com/watch?v=QNF0MYfylW4) ## In this lesson Roy Osherove presents [feature flags](https://pipelinedriven.org/feature-toggle-frameworks-list "Feature Toggles (pipelinedriven.org)") as what completes [continuous delivery](https://pipelinedriven.org/article/continuous-delivery-values "Continuous Delivery Values (pipelinedriven.org)") 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 824 words [\[00:03\]](https://www.youtube.com/watch?v=QNF0MYfylW4&t=3s) Let's talk about [feature flags](https://pipelinedriven.org/feature-toggle-frameworks-list "Feature Toggles (pipelinedriven.org)"). The final nail in the coffin to create [continuous delivery](https://leanpub.com/pipelinedriven "The Holy Grail of Continuous Delivery (pipelinedriven.org)") 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\]](https://www.youtube.com/watch?v=QNF0MYfylW4&t=42s) 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\]](https://www.youtube.com/watch?v=QNF0MYfylW4&t=72s) 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\]](https://www.youtube.com/watch?v=QNF0MYfylW4&t=104s) 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\]](https://www.youtube.com/watch?v=QNF0MYfylW4&t=136s) 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\]](https://www.youtube.com/watch?v=QNF0MYfylW4&t=173s) 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\]](https://www.youtube.com/watch?v=QNF0MYfylW4&t=205s) 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\]](https://www.youtube.com/watch?v=QNF0MYfylW4&t=236s) 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\]](https://www.youtube.com/watch?v=QNF0MYfylW4&t=268s) 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. ## Related - [Feature Toggles](https://pipelinedriven.org/feature-toggle-frameworks-list) · pipelinedriven.org Roy's list of feature toggle (feature flag) frameworks by language, including Python ones like those shown for Django. - [BBBCTC - Branching, Binaries, Builds, Coding and Testing Culture](https://pipelinedriven.org/article/2015/5/30/bbbctc-branching-binaries-builds-coding-and-testing-culture) · pipelinedriven.org Roy on developers learning feature toggles to work on the main trunk without breaking everyone's code. ### Also linked in this lesson #### pipelinedriven.org - [Continuous Delivery Values](https://pipelinedriven.org/article/continuous-delivery-values) - [The Holy Grail of Continuous Delivery](https://leanpub.com/pipelinedriven) [Previous lesson Release Branches](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/release-branches/) [Next lesson TeamCity CI and Artifacts](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/teamcity-ci-and-artifacts/) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/