Since a couple of weeks I follow a controversial topic on twitter which I would describe as the “anti-feature-branching” movement. In a previous post I have already written about feature branching and why someone would recommend to not following such a successful branching model.

The solution to many daily problems a typical developer is facing when applying feature branching will be solved by doing Trunk Based Development. If you integrate daily instead of waiting until the complete feature is finished, the merge won’t be a big deal. However, the merge conflict of integrating a completed feature after a few month into mainline could be a big mess. I think that is something every developer has experienced already.

So the recommendation is to integrate often. Following this approach is easy if you create new features. Instead of developing them on a separate branch you simply add the new files directly to mainline and make sure the new feature won’t be visible by turning it on and off with a simple feature flag.

But what if we have to change the behaviour of an existing feature? That is where the concept Branch By Abstraction comes in. And no, the word branch does not stand for  git checkout -b ;-). In fact, an architectural design concept is meant. You first spot the point where you have to apply the change. There you create a new abstraction layer. That layer describes the communication between the original module and the client. Then it is easy to create a new module which extends the existing one or alters its behaviour.  As long as the new module is in development we can stick to the old module. Just in development environment we switch in the new module for testing and developing purposes.

Don’t forget to clean up!

Once the change is implemented completely we can also activate the new module in production mode. That is the point where we need to clean up to keep our code clean. If the old module is not used anymore just remove it and remove the feature flags, too.

I do like this approach a lot since it forces the developer to think about abstraction layers which is crucial for a good system architecture. Plus, there are some positive side effects when having feature flags in place. It offers the possibilities to do a rollout in small increments by enabling the new features just for a small subset of your customers at first.

Check out the talk about”Feature Branches and Toggles in a Post-GitHub World” by @samnewman for further information. He gives some nice examples and explains the downsides of feature branching.