axelhodler

Trunk based development

At my first real job, back in 2014, we were using the version control system svn for the backend. The mainline branch - think master or main in git terms - was called trunk.

Every developer pushed changes straight to mainline (trunk). There was no code review before adding changes to mainline. Me, having worked with git previously - in fact most projects in the company where using git already - thought this was subpar. Almost awful. Not the way things are done in modern software development.

Later someone was added to the team in charge of moving us to continuous delivery. When discussing branching strategies yours truly, being an avid reader of hackernews and all things development related, was eager to push for Gitflow.

The response I got back was

Yeah, but thats not really continuous delivery

Boy was I shaken. Isn’t this the cool git branching model everyone is using?

Back then I did not get it. Mostly because we did what most folks do. Have our own definition of what continuous is supposed to be.

In our case it was after every sprint. A release every two weeks - If, and only if, nothing goes wrong.

Of course every two weeks is better than every few months. And every week is better than every two weeks. But not what I would consider continuous today.

We ended up having feature branches, some short lived (days), some long lived (months). These changes were moved to mainline after one or more reviews.

The workflow had its issues but was, from my perspective, way better than to contributing straight into mainline.

Years later, when Microservices were all the rage, I watched a talk by Sam Newman

Some of his comments on Gitflow in the talk

Because if there is something worth doing, there is something worth doing really complicatedly

I don’t understand all this because I’m old and quite stupid

Every single picture that shall explain to me how Gitflow works just makes we want to kill myself

Well the last one is an exaggeration. But taking the

I don’t understand all this because I’m old and quite stupid

from a guy of his calibre is quite humbling.

Today I would agree.

Getting to “short lived” “feature branches” is hard. Both due to a definition what “short lived” is exactly and the common question how the whole “feature” - it’s a “feature branch” after all, can be implemented in a few days, or even hours.

If we get quick reviews, meaning colleagues get into the review ASAP instead of once or twice a day, we might get small branches and thus small pull requests (PR)

And if we have feature toggles in place like

if current_user_sees("our_awesome_future_feature"):
  show_new_feature()

and thus only specific users, or groups, will be able to see the new functionality in production. We can split the feature into

See Structuring work for continuous integration for more examples.

Or as Kent Beck calls it

First make the change easy, then make the easy change

If we don’t get quick reviews the developers will bundle these changes into one big change. This automatically leads to longer lived feature branches.

To avoid the hassle of slow reviews we can try adding a second pair of eyes right away by pair programming or even multiple pair of eyes by mob programming.

Instead of having multiple branches we push small changes into main, or master, or trunk. Together as a team.

That is trunk based development.

Trunk can always be released. It could even be released on every push. That’s the strategy.

Users will not care about unfinished features because they will not see them.

Only the developers. Or any other group configured to see them. When the feature is done the flag can be removed and everyone is able to see and use it.