Feature Toggles vs Feature Branches

Question

What are "Feature Toggles" and "Feature Branches" and what's the difference between them?

What are the pros and cons? Why is one better than the other?

I found some articles on Google regarding this, and I tend to be in the "Feature Toggles" camp, but I'm not convinced that "Feature Toggles" is the better choice in all the cases.

Two things in addition to the answers below: You cannot have both Feature Branches and Continuous Integration (unless you set up automated builds for each feature branch), and if you decide to go for Feature Branches, arm yourself with GIT (or similar) that has powerful merging capabilites. I would also recommend reading the book "Continuous Delivery" by Jez Humble. — spacedoom, Oct 19 '13 at 22:26
@spacedoom: " You cannot have both Feature Branches and Continuous Integration" - I disagree. Many CI solutions have explicit support for building feature branches. Jenkins for example can even automatically create build jobs for any feature branches it detects in the SCM. — sleske, Jul 15 '15 at 20:21

score 48 · Accepted Answer · edited Sep 22 '17 at 18:30

48

Feature toggles are methodology used in a Continuous Integration/Continuous Delivery (CI/CD) chain (Agile/Kanban project methodology). Basically, you send new features to production in a disabled state, then in an admin console turn the feature on (or off if you discover it's broken).

Feature branches can be part of a release methodology and integrated into a continuous integration chain. You can develop in a feature branch, deploy the branch to DEV/QA, get certification, merge the feature branch to trunk, then push the trunk to SIT/UAT/PROD environments.

There are pros and cons associated with this approach. Feature toggling requires very strict discipline as broken/dark code is making it to production. This is great for startups and shops where management knows how to pull this off and has system automation tools in place (Chef/Puppet/cfengine, etc.) Google, Facebook, LinkedIn, WordPress all deploy to production environments using feature toggling and system automation.

There are some prerequisite "techs" to do feature toggling properly: Continuous Delivery/Deployment, Continuous Integration, Automated Unit Testing, Automated Integration Testing, Automated Stress/Performance Testing, System Automation. If you don't have these in place, consider a simpler release strategy (e.g. feature branching.)

edited Sep 22 '17 at 18:30

nsprenkle

191
11

answered Oct 17 '13 at 18:44

Electrawn

2,156
16
23

7

I think the last paragraph is backwards: _"Here are the pre-requisite "techs" to do Feature Toggling properly: Continuous Delivery/Deployment, Continuous Integration, Automated Unit Testing, Automated Integration Testing, Automated Stress/Performance Testing,System Automation"_, feature toggles are a pre-requisite to be able to do CI/CD, not the other way around. At least that's my takeaway from reading [Martin Fowlers article on the topic](http://martinfowler.com/bliki/FeatureToggle.html). – pgpb.padilla Sep 25 '15 at 18:10
2

I disagree with the last paragraph a little. Suggesting that you need all those structures running before you can Feature Toggle (and get all the awesome "get stuff to prod now" value it delivers) is not only *not true* but it's going to scare folks. All you need is a good CI/build pipeline and the prod environment ready so you can push to it when you need (doesn't have to be CD). I get what you're saying tho, if you have CI/CD then you should already be doing Automated Testing of various flavours (unit/integration/full-stack,etc) but it's not a solid requirement. – Matt Kocaj Jan 22 '16 at 06:45
FWIW, here is a simple package for .NET web apps which makes it easy to toggle in various ways, allowing you to get on with shipping stuff to prod and not worrying about the infrastructure: https://github.com/cottsak/DevCookie – Matt Kocaj Jan 22 '16 at 06:46
1

Automated testing in as much as possible flavours is recommended and necessary also for feature branching (and whatever other possibilities of development). – Uwe Allner Mar 14 '16 at 09:06
Excellent answer. Just adding on top of it: a lot of companies couple product-go-live with a software release - with feature toggles this is not the case; you will be deploying sooner & simply turning it on when the day comes. This leaves you a lot of time to iron out deployment/release issues. – Kevin D. Mar 10 '20 at 00:46

score 23 · Answer 2 · edited Jul 15 '15 at 20:23

23

I discuss this in depth on my blog: http://geekswithblogs.net/Optikal/archive/2013/02/10/152069.aspx

In short, feature branches will give you better isolation, but require you to deal with the pain of deferred integration, and merges. Toggles give you continuous integration, but require you to design/implement your code in such a way that supports toggles, and introduce the risk that unfinished feature code could negatively affect production.

You can use both branches and toggles together (they aren't mutually exclusive). As far as deciding which one to use in each scenario, my thoughts are that toggles should be the default choice unless the following are true:

hard to hide the functionality behind a toggle
has a potential impact on an area of the application that doesn't have thorough tests

If either of those conditions are true, I would probably use a feature branch instead of toggle.

edited Jul 15 '15 at 20:23

sleske

73,934
32
166
212

answered Oct 17 '13 at 22:21

Dylan Smith

21,401
2
45
58

Very nice blog post. Thanks for sharing – Hamid Shahid May 07 '14 at 22:39
1

It seems that most people assume integration has to happen always in a single direction `feature branch -> main`. I've seen a lot of success doing it the other way around, continuously integrate by pulling the latest from `main` into the `feature branch` so that at the time you need to integrate back to `main` your merge is a fast-forward one, hence painless. – pgpb.padilla Sep 25 '15 at 18:13
A simple package I built that makes it easy to hide functionality behind a toggle in a variety of ways https://github.com/cottsak/DevCookie – Matt Kocaj Jan 22 '16 at 06:41

score 5 · Answer 3 · answered Oct 17 '13 at 19:33

Feature toggling requires very strict discipline as broke/dark code is making it to production.

I agree Electrawn, I've been using feature branching along 6 years, because in our case, we haven't the pre requirements.

Also is important to understand that the "Toogle Strategy" transfers the effort spent in Feature Branches Strategy( Merging ) to another moment.

http://martinfowler.com/bliki/FeatureToggle.html

It's very important to retire the toggles once the pending features have bedded down in production. This involves removing the definitions on the configuration file and all the code that uses them. Otherwise you will get a pile of toggles that nobody can remember how to use. In one memorable example I heard of, it required making a special recompilation of the linux kernel to handle enough command line switches.

Note: Following the SCM principles if anybody open and edit a file it could be broken code.

So, In my perspective I don't believe in a "better choice in all the cases", because it depends on the culture of your team and if u have the test cover.

Well it is a very polemic question.

I still prefer Feature Branches Strategy in my case. Keeping the SCM best practices and planning the roadmap, the merge process tends to be a easy way. During these year, i heard a lot of people complains about merge process, but in much cases the problem of merge is the same in my experience, "The communication fails" :)

Sorry for unprecise answer, but i think there are some humans aspects around this subject of better choice in SCM.

I can write unit test to verify if a toggle is behaving properly whereas feature branches just means I'm deferring merging until the last minute, and then spending hours with my coworker fixing conflicts. I feel feature toggles are more predictable. — Kevin D., Mar 10 '20 at 00:50
Nowadays, we having been applying toogle strateg as well @Kevin D :) , but is very important keep remving toogles. Also, we are using GIT FLOW, and toogle is a compatible strategy for keep code status "Ready to Production" — Eduardo Fabricio, Mar 10 '20 at 22:18

Feature Toggles vs Feature Branches

3 Answers3

Linked