4 ms·
Branching or not is somewhat of a red herring. If you are working on a commit then while you haven't pushed that commit, you're effectively working on a branch.
by jules 11y ago
Branching or not is somewhat of a red herring. If you are working on a commit then while you haven't pushed that commit, you're effectively working on a branch. If somebody else works on the same code at the same time, then those changes need to be merged. Whether your VCS does or doesn't call that a branch is immaterial. What matters is that two developers can work on the same code at the same time, and that you need to solve concurrent editing conflicts (logical ones, not just the textual ones that your VCS will find).
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.
- aidenn0 11y agoThis 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.
- zeendo 11y agoKeep 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.
- aidenn0 11y agoFeature 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.
- OldSchoolPro 11y agoUse automated integration tests and test every combination.
- aidenn0 11y agoExponential runtime.
- OldSchoolPro 11y agoDon't overdo it, use coarse grained switches. Throw hardware at it. Switches are temporary, with time their number will settle.
- aidenn0 11y agoThe 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.
- xorcist 11y ago"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.
- dllthomas 11y agoIt 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...