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.

Communal

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. – Hitchhike

@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. – Haematin

More info https://mcmap.net/q/173059/-what-is-a-quot-feature-flag-quot – Lepidolite

Answer 1

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.)

Milano

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. – Montagnard

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. – Lepidolite

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: github.com/cottsak/DevCookie – Lepidolite

Automated testing in as much as possible flavours is recommended and necessary also for feature branching (and whatever other possibilities of development). – Abed

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. – Daisydaitzman

Answer 2

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.

Amaranthaceous

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. – Montagnard

@Montagnard this only works if you have one (large) feature branch at a time. If you have multiple going on in parallel, there is no one branch that mostly can do fast-forward: As soon as on feature branch does it and merges to main, you have again a big merge and deferred integration of the merged code into your other feature branches. – Interline

Answer 3

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.

Gunyah

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. – Daisydaitzman

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" – Gunyah