3 ms·

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/implemen

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).

ainiriand 1y ago
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.
- coolgoose 1y ago
  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.
- MichaelNolan 1y ago
  > 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.
  - ainiriand 1y ago
    In our case we are 3 devs.
    - SenHeng 1y ago
      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.
- Disposal8433 1y ago
  > 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?
  - JimDabell 1y ago
    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.
    - ansgri 1y ago
      That requires the ability to fully test it locally, which unfortunately is uncommon in decent-sized systems.
Disposal8433 1y ago
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-of-feature-branching-the-problems.html 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.
- JimDabell 1y ago
  > 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.
  - Disposal8433 1y ago
    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.
    - JimDabell 1y ago
Izkata 1y ago
> 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.

ainiriand 1y ago

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.

coolgoose 1y ago
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.
MichaelNolan 1y ago
> 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.
- ainiriand 1y ago
  In our case we are 3 devs.
  - SenHeng 1y ago
    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.
Disposal8433 1y ago
> 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?
- JimDabell 1y ago
  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.
  - ansgri 1y ago
    That requires the ability to fully test it locally, which unfortunately is uncommon in decent-sized systems.

Disposal8433 1y ago

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-of-feature-branching-the-problems.html 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.

JimDabell 1y ago
> 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.
- Disposal8433 1y ago
  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.
  - JimDabell 1y ago

Izkata 1y ago

> 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.