Feature toggles are a good option too; I have used that before and like it. The downside is that you can end up with a giant set of feature toggles and very little idea of which combinations work.
It sounds like you need some way of applying downward pressure to the number of feature toggles, so they get cleaned up when no longer relevant. I don't have an immediate suggestion, though...
Re:Branchless development
by OldSchoolPro on Sunday July 19, 2015 @01:03PM
(#9911828)
Use automated integration tests and test every combination.
Exponential runtime.
Re:Branchless development
by OldSchoolPro on Sunday July 19, 2015 @02:36PM
(#9912285)
Don't overdo it, use coarse grained switches.
Throw hardware at it.
Switches are temporary, with time their number will settle.
"It's just temporary" is one of the five famous last words (together with "it worked on my machine"). It can easily turn into one of those projects where someone just shoved in autoconf to turn them into a giant ball of IFDEFs so nobody really knows which combinations work.
Toggling also only makes sense for the cases where you don't change the structure of your data. So be careful, and make sure you have a plan if you decide to do it.
The one place I worked that used them, switches were not temporary. There were about 4000 of them last time I checked.
There was an advantage: if a bug popped up you possibly had a workaround immediately for the customer. Downside is you had no idea if that workaround would expose more bugs.
Feature toggles remove this problem by keeping everyone in trunk/master. You can then have CI builds with whatever set of toggles you want.