1 like
·
256 reads
2 comments
Really interesting take Curtis!
TBH I wasn't aware that trunk-based development really means NO branches at all. From what I understand so far is that we have one trunk branch where all changes get merged (even with PRs).
One of the main differences for me is to have one ground truth code (which is the trunk branch) and that the pipeline is taking care of the rest.
For example, instead of having a development branch that only merges to the dev stage and a main branch that only deploys to production we have one branch and the pipeline takes care of both.
By having that we simply don't diverge from the two stages at all.
Probably my definition is simply wrong but I like that model a lot!
Difficulties
I do see some difficulties in trunk-based development also. For example, if Dev A merges code to the trunk and after the dev stage was deployed the dev recognizes a bug. That is the point where we have faulty code in the code base. Every dev who creates a branch now has the "bad code" in his feature branch.
So trunk-based development specifically emphasizes the practice of not creating short-lived branches. It’s popular in pure agile and pure CI/CD workflows. In both that and the PR model, there is absolutely a branch that represents the “ground truth code” you speak of.
It’s possible you’ve heard of this ground truth branch as the “trunk” — but just because it exists, doesn’t mean the team is performing trunk-based development in practice. I think the nomenclature is one of those a points of contention described in Lorin’s article, where we use agile terms, when we’re not actually participating in agile development.
To your point, pushing bad code to the trunk is one of those tough problems to work around, especially in trunk-based development, where everyone works on the ground truth branch, assuming it’s working and correct.