This is super-important; it is far better for a developer to push a non-working feature on a feature branch than for them to leave it on their machine. They ought to do whatever the equivalent is of a git rebase every morning or evening, so that it is still at least nightly integrated for them.
Keep in mind though that if everyone is working on something that takes multiple days to complete (and your definition of non-working is incomplete) then all the work is happening in feature branches and master is quiet. Those rebases are easy because no work is going on there.
Feature toggles remove this problem by keeping everyone in trunk/master. You can then have CI builds with whatever set of toggles you want.
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.
The pertinent question is how often you merge. On one end of the scale you merge on every keystroke. Every time Joe types a character it gets put into Anna's files. Clearly this doesn't work. On the other end of the scale every developer works on their own copy, and all the work gets merged just before a release. Clearly this doesn't work either. There is a scale from maximal disruption minimal effort merging to minimal disruption maximal effort merging. You want to find a point on that scale that minimizes the total amount of work.