Branch by abstraction and trunk based development

Posted by on 9 June, 2013

Recently I have been trying to figure out the best way to handle parallel development of bug fixes and new functionalities.

As I am using GIT (in front of an SVN repo) I thought about feature, release and hotfix branches as described in the excellent blog post A successful Git branching model by Vincent Driessen. Best used with the gitflow GIT extensions.

The model explains that “feature branches typically exist in developer repos only, not in origin” but this is not feasible for our team. Some feature branches take long to be developed (> 1 week, often > 1 month). You should not keep more than a couple of days work on your developer machine without pushing to the repository. (YMMV of course.)

Peer-reviewing a whole feature branch when development is finished (and merged and pushed back to the repository?) is just too hard. We like to review commit-by-commit — changes are much easier to follow and understand that way. If everyone on the team would use GIT we could push/pull changes to each other but this creates a lot of branch management overhead especially if you have many parallel feature branches. (At one point we had 9 feature branches and 6 release branches, at the same time.)

After more than a week branches are also very disconnected from development in other branches or the main develop branch. Merging (especially after refactoring or rewriting) becomes very hard.

We also have features (i.e. feature branches if using the branching model) waiting to be merged and deployed for several months after development is finished. Such branches cannot stay in the developer repos only. This also has the side effect that more and more branches are active in parallel.

Long story short, feature branches do not work for us.

Enter branch by abstraction and trunk based development.

Paul Hammant best described it in several articles on his blog.

Basically, “you can convene large sets of developers in a single trunk (Trunk Based Development) and avoid “short lived feature branches” that you have to merge back.”

Some advantages are that everyone commits everything in the main develop branch, everyone can review every commit immediately, there are no problems with someone doing a refactoring or rewrite, everyone’s local repository copy is always up-to-date with the latest development, and the whole repository is always completely tested by the continuous integration system.

You will want to use feature toggles (or build-time toggles, etc.) so that you can always go to production with an unfinished feature implementation. Toggles also allow you to choose the implementation per environment (DEV, TEST, PROD…) and you might be able to activate the new feature or implementation while the server is running (i.e. no new release is necessary, hot deploy).

I will not try to summarise Paul Hammant’s blog posts here because he explained everything perfectly in the following articles. They are a must read for every developer.

To conclude, branch by abstraction and trunk based development in combination with feature toggles seem to work very well for our team. All developers can easily follow all new development and do peer-reviews per commit and our continuous integration system makes sure nothing gets broken.

Some more interesting reads:

development, ,

Comments are closed.