Feature Toggles vs Feature Branches
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.
3 Solutions collect form web for “Feature Toggles vs Feature Branches”
Feature Toggles are part of a Continuous Integration/Continuous Delivery chain (Agile/kanban Project Methodology). Basically, you send new features to production in the off state, then in an admin console turn the feature on (or off if you discover its broke).
Feature Branches (can be) part of a Release methodology and integrated into a continuous integration chain. You can be trunk stable/trunk unstable. If you are trunk stable, you develop in a feature branch, deploy that to branch to dev/qa, get certification, merge the feature branch to trunk, then push trunk to SIT/UAT/PROD environments.
Each has pros and cons as release Methodology goes. Feature toggling requires very strict discipline as broke/dark code is making it to production. Great for startups and shops where management knows how to pull this off and have System Automation in place.(Chef/Puppet/cfengine, etc)(Google, Facebook, Linkedin, WordPress all deploy to Production environments using feature toggling and System Automation)
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. if not, consider a simpler release strategy (i.e., Feature branching)
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.
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.
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.