Feature Toggles, Feature Branching and Branch by Abstraction
Note: For people who argue only one of it is good, please read this. Its written by Fredrick Brooks, one of the seminal guys in software engineering.
Purpose: Main aim of this article is to spur a thoughtful discussion around the topic than religious opinions or fear mongering about how other option is scary.
There is so much of debate around feature toggles and feature branches. Most of the existing literature seems to be around each one of it rather than contrasting them and giving a holistic picture. Some of the ones that do give like this seems to be missing the big picture. Here is my attack at the whole situation.
Why These?
Before we delve any deeper lets look at the various reasons around why we would need these techniques in first place.
1. Ability to release at any time. Delay in the development of a particular feature does not halt the entire production release cycle.
2. Ability for the business to hide features / AB test them / do a delayed release of a particular functionality / back out a particular feature.
For purposes of argument, this article will focus only on 1. Look here for debate around 2.
The Promise of Feature Toggles:
1. Continuously integrating changes in CI and if anything goes wrong could be reverted back.
2. Functionalities can be switched off if the integration does not go well.
3. No merge hell / Semantic merge conflicts
4. Code changes made are immediately in trunk available for the entire team for review.
To Note:
1. Feature Toggles aren’t necessarily used only in case of Large features, it could be used to hide certain functionalities that could be as simple as introducing a field to a form.
Arguments against Toggles:
1. Every Toggle added to the system needs to be checked with state on and off. So the more toggles in system would mean more combinations to test.
2. Some toggles cannot be clearly done in a clear way. In some places it could be as simple as a change in the injected object to if statements clobbered everywhere across the code.
3. Since feature toggles themselves involve code, we could accidentally be exposing something that’s potentially untested / that should not be displayed(How do you think the apple rumours(like this) are fuelled anyways?)
4. The longer the Toggle is existent in the system, the more expensive it is.
The Promise of Feature Branches:
1. Well tested code after QA’ing ends up in master.
2. Master can be deployed at any arbitrary moment.
3. Ability to track which changes went to each story/feature.
4. Ability to isolate noise when working on something big like a refactor(note: large refactoring is usually bad and should be done incrementally as much as possible).
Arguments against Branching:
1. Delays Testing(wait, am I getting wrong or qa’s don’t start testing until we call the story complete, in case of feature branching its after developer calls it complete.)
2. Merge Hell and Semantic Conflicts.
3. Integrating with CI less often.
Feature Bits
1. The arguments in feature bits of Facebook kind of invalidates the whole statement
Authoritative Articles about the subject.
http://techcrunch.com/2011/05/30/facebook-source-code/
https://www.facebook.com/video/video.php?v=10100259101684977&oid=9445547199&comments