Comment by Ozzie_osman | Hacker News Reader

Comment by Ozzie_osman | Hacker News Reader

What they are describing as "Trunk-Based Development" seems a little extreme, and frankly, I'm not sure how achievable it is. Generally, when I've seen/implemented TBD it has involved Pull Requests and code reviews (they seem to imply it shouldn't). With their definition, I think a few issues arise: * Even if you think you can have high quality without PRs, in many industries, it's part of security/compliance. * They say that PRs undermine shared ownership, when actually, PRs done right can enable shared ownership (yes, I can't just merge whatever I want, but also, I get to help ensure no one merges whatever they want).

They also say that "no branches are created". In reality, I don't see how you do any modern development without branches. If anything, contributors need a local branch that is then merged to the trunk (unless, somehow, everyone is live-editing the main branch?). The idea of TBD is just to have smaller, short-lived branches that are frequently merged into main (very doable with pull requests).

Perhaps I can shed some light into your questions as I work on TBD since 3 years now.

In our case there are no Pr's, we push to master, the test suite is triggered, the dev environment receives the new code. It moves to other environments if the tests pass. We release to master using a canary instance that gets only a small share of the traffic, if our metrics for success fail then we rollback and start a hotfix. Yes you can have as many branches you want in your local but in the remote there is only one.

And how is that different than just doing a pr, and merging to trunk?

It feels like you are just canceling a lot of pipeline tests all the time, assuming there's a cadence of 10+ pushes per day.

> In our case there are no Pr's, we push to master

Just to clarify, are you saying there is no code review where another engineer looks at your change before you merge to main?

I’ve never seen a TBD project work that way. I can’t imagine how it would work for anything but the smallest teams.

In our case we are 3 devs.

I have been in projects where I am the sole dev, and I still create PRs and self review them before merging.

I do this because I am human and make mistakes.

> we push to master, the test suite is triggered

If you have a bug due to the last commit, don't you have to write fixes all the time? How do you review the code?

You make sure it works first. Are you opening PRs with bugs “all the time”? Why? Nothing is ever bulletproof, but bugs shouldn’t be the norm in new code.

That requires the ability to fully test it locally, which unfortunately is uncommon in decent-sized systems.

It is indeed extreme and very limited to writing web applications in a specific context. That is not how I have been working for the past 20 years, and his solution would be destructive in my daily job.

One of his previous article (https://thinkinglabs.io/articles/2022/05/30/on-the-evilness-...) takes it one step further. It seems that everyone works on everything at once and people step on each other toes all the time. They would definitely improve by using the feature branches that they shun.

Last but not least, he's talking about quality, high-trust, or on-demand build which are topics unrelated to a branching strategy. Quality is done with local tools like linters and CI to prevent bad merges, and on-demand build can be done with tags in any branching strategy. The whole article is confusing actually.

> everyone is working on a single mainline

It's the same for every strategy. And TBD mentions release branches, so... he's wrong in the very first sentence.

I do like TBD though because it's a clean way to handle release and feature branches, but that's it.

> It is indeed extreme and very limited to writing web applications in a specific context

It’s not. I’ve used TBD for mobile apps and it’s been great. I do prefer short-lived branches with PRs (which is another form of TBD), but it’s wrong to say that their approach is limited to web apps in a specific context.

It definitely is. He's saying that "we uncover more problems sooner" which can only be done on systems such as web sites where the tests and their results are done very fast. Where I work we can have weeks of testing to make sure that every feature has not introduced a bug.

I'm not criticizing TBD which I like, I criticize his thoughts that it's related to TBD where in reality the whole article talks about his specific job and the organization of his team, which again is unrelated to any branching strategy.

> It definitely is.

So are you saying I just imagined using this for non-web projects?

> He's saying that "we uncover more problems sooner" which can only be done on systems such as web sites where the tests and their results are done very fast.

I don’t understand why you think this. Uncovering problems quickly is one of the major points of continuous integration and it’s in no way limited to the web.

> Where I work we can have weeks of testing to make sure that every feature has not introduced a bug.

This does not mean that branchless TBD is limited to the web, it means that it’s not suitable for your project.

You misunderstood everything to the point I think you're doing it on purpose.

I like TBD, but the article is NOT about TBD.

> are you saying I just imagined

I use TBD for everything and I like it. I was talking about the writer of the article, not you. The article is, again, NOT about TBD and the writer, most likely an overpriced consultant, is very confused about branching strategies, and most likely believe that a daily standup or some pair programming is part of that strategy. His other articles confirm this.

You said it was limited to web projects, I said I had used it in non-web projects and it wasn’t limited to web projects, and you said “it definitely is”. How else am I meant to interpret that? You are directly saying that what I have personally experienced isn’t possible.

> The article is, again, NOT about TBD and the writer, most likely an overpriced consultant, is very confused about branching strategies, and most likely believe that a daily standup or some pair programming is part of that strategy.

This does not resemble the article we are commenting on.

> If anything, contributors need a local branch that is then merged to the trunk (unless, somehow, everyone is live-editing the main branch?).

The term originates in the svn or earlier era (hence "trunk"), when "commit" and "push" were the same operation. So there wasn't really such a thing as a local branch, just uncommitted changes. And svn was able to commit changes to any files that no one else had committed to yet, it wasn't whole-repo versioning like git that required you to be fully up-to-date before pushing.

Reply on news.ycombinator.com