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.

Answer 1

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.

Answer 2

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

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.