So we very much follow the principles of continuous integration, which is not something you can do at the same time as feature branching.
- Martin Fowler
Fowler advises to use Feature Toggles instead of Feature Branches for the development of features that takes longer than a release cycle or features that the business does not want to have released yet.
I should also point out as well I do advocate using feature toggles for features that take more than a release to implement, but it’s only the second best solution in that case. The best solution is to find a way to release the feature’s capabilities incrementally and usually you can do that and people need encouragement to go down that path. And only when you can’t and absolutely can’t should you use toggles.
- Martin Fowler
These are interesting concepts and I wonder if they are equally valid for all kind of projects?I think this advice is mainly aimed for projects with a compact, dedicated team with clear goals that is aiming at striding forward at a sustainable pace.
In open-source on the other hand, I see a flourishing ecosystem of projects where people are working together in a more loosely coupled way. "Social coding" on GitHub is the best example here, where forking and submitting patches is made ridiculously easy.
Here I see the concept of feature branches as a very sensible concept...
Very interesting, thanks.
ReplyDeleteOn your last point: There is still the problem of a big bang integration that is then up to the chief(s) of the project.
Feature branching works, but it is not very efficient and predictable. The same will apply to your open source project.
Probably the next github will include CI...
@Bertolami
ReplyDeleteTrue. The big bang integration is still a problem.
But my observations from GitHub is that feature branches (respective easy forking and pulling back) enable a very organic evolution for a project.
A lot of the forks / feature branches will never survive (never be merged back). But they allow for easy experimenting (like natural mutation in nature :-)).
The more such mutations you have, the bigger is the chance that finally something useful will result and survive ...
In more "centralized and focused" projects, the experimenting aspect is much less important and on a much smaller scale. Experiments are usually planned and tracked and have a clear scope. The desired outcome is to have them merged.
While in open source the primariy goal is to enable experiments, merging the successful ones is only the second concern.
Agree.
ReplyDeleteBut this is also an explanation of one of the issues with open source software: Too many features.
Each developer is a product owner? And to keep the developers happy, the chief(s) accept more features than necessary... And don't "put a lot of effort into removing features" http://bit.ly/duWJIR
Interesting observations!
ReplyDelete@Bertolami
ReplyDeleteBig bang integration is only a major problem if you allow to let feature branches get stale. Of course, with traditional SCM tools this was nearly always the case as they didn't do merge tracking, thus an easy update of the feature branch with the latest changes from the main development line was not possible.
This has completely changed with the new DSCMs. The integrator (doesn't have to be a chief anymore) just won't do an integration of a stale branch on the main code line, they will simply ask the responsible developer to update the feature branch. The typical tell tale sign of a stale branch are non-trivial conflicts, easy to recognize - you could do even automated trial merges upfront and notify the developer about the outcome.
Of course, you still will have a certain number of last minute features just before feature freeze day. But they will only possibly conflict with each other but not with the stuff which was integrated over the last weeks. Usually this will result only in very few problems. And it has a nice little educating effect. If you do integration in strict order of arrival the later developer/teams will do more conflict resolution work than the earlier ones. If you combine this with a train model and big bang integration is a thing of the past.
I see it this way: Small compact teams with short build and testing cycles should do Continuous Integration on the main development line. Bigger teams working on huge code base with long build and test cycles are better of to do "Continuous Update" of the feature branch with the main code line.
In that very article you linked (Feature Branch), Fowler already states that he thinks CI is good for projects where developers work at similar speeds (i.e. employees), whereas Feature Branching is probably better for Open Source projects, where developers may have very different speeds due to different effort put into the project.
ReplyDeleteYou are just repeating Fowlers point in different words.
I'm collecting articles and posts with criticisms to Martin Fowler's argument against Feature Branching. I'm very interested in Continuous Integration, but somehow I feel half the story has not been told.
ReplyDeleteFind here some posts to dig into this topic:
Help me, because I think Martin Fowler has a Marge Paranoia
Continuous-Integration vs Continuous-Perfection
Why does Martin Fowler not understand Feature Branch
Feature Branch vs Continuous Integration