3 ms·

Isn't "trunk based development" just a complete crock of shit?

7 points by GarethX 2y ago

deleted 2y ago
[deleted]
taylodl 2y ago
There's no single approach that works for everybody. What works best for you is dependent on several factors: - Whether you're primarily developing or maintaining - Size and organization of the codebase - Size of the team working with the codebase - Your production deployment strategy - Probably others Here's the thing: I know teams using trunk-based development and teams using feature branch development, and they all work in the same organization! Like most things in software development, the best strategy for you is dependent upon your needs and you should eschew the idea that there's only one right way to do everything.
- SideburnsOfDoom 2y ago
  You cannot assume that in business, because a team is using a particular method, that this method is optimal, i.e. that it "works best for them". More often, it's just what they ended up with, and changing methods is hard. It may even be actively resisted. Teams need to be encouraged to "inspect and adapt".
  - taylodl 2y ago
    > Teams need to be encouraged to "inspect and adapt". Agree 100% and that's on excellent callout.
  - pjc50 2y ago
    Sure, but there's also often a difference of opinion within the team and switching costs may be real and large. I'm not a fan of gerrit, which my current workplace uses, but I'm also resisting a move to github because doing so would involve rewriting a lot of CI scripts.
    - SideburnsOfDoom 2y ago
      Indeed, the local optimum is in avoiding any drastic changes, which should not be made often or lightly. Switching costs and inexperience will drag you "through the valley" when making them with existing projects. I read "best" as global optimum but I know that's not the whole story. And working with like-minded colleagues on ideas such as this, is a very nice thing to have. It is something to seek out when looking for a new role.
PaulHoule 2y ago
It was the only way you could do it (reasonably) with CVS because the branching model was primitive.
- SideburnsOfDoom 2y ago
  Sure, far more complex branching strategies are now possible. This is a different question to "is this advisable?" Just because you can do something complex, doesn't mean you should. Avoiding this complexity can be beneficial. Yes, some of the complexity might show up somewhere else instead. But which place is the best place for it? Maybe, trunk-based development is the idea that "branching strategies are not the right place to put that complexity".
pjc50 2y ago
Slightly confused as to what is not trunk based development if TBD can include branches.
- SideburnsOfDoom 2y ago
  I am of the opinion that raising a pull request (which is a kind of branch) off main, then getting review, approval and a merge within an hour counts as trunk based development. But if there are long-lived branches, or a "release branch" which means that main is not what is deployed to production, or that main/"the trunk" is not what is merged onto, then you are definitely not doing trunk based development.
SideburnsOfDoom 2y ago
> doing small short-lived branches of coherent chunks takes practice but it’s very possible. Indeed, chunking and sequencing changes is a learnable skill, like many other things such as system design, effective unit tests, or writing code that compiles in the first place. Out of those it's not the hardest - it's hardly like learning a new programming language - and it is very beneficial.

7 points by GarethX 2y ago

deleted 2y ago

[deleted]

There's no single approach that works for everybody. What works best for you is dependent on several factors: - Whether you're primarily developing or maintaining - Size and organization of the codebase - Size of the team working with the codebase - Your production deployment strategy - Probably others Here's the thing: I know teams using trunk-based development and teams using feature branch development, and they all work in the same organization! Like most things in software development, the best strategy for you is dependent upon your needs and you should eschew the idea that there's only one right way to do everything.

SideburnsOfDoom 2y ago
You cannot assume that in business, because a team is using a particular method, that this method is optimal, i.e. that it "works best for them". More often, it's just what they ended up with, and changing methods is hard. It may even be actively resisted. Teams need to be encouraged to "inspect and adapt".
- taylodl 2y ago
  > Teams need to be encouraged to "inspect and adapt". Agree 100% and that's on excellent callout.
- pjc50 2y ago
  Sure, but there's also often a difference of opinion within the team and switching costs may be real and large. I'm not a fan of gerrit, which my current workplace uses, but I'm also resisting a move to github because doing so would involve rewriting a lot of CI scripts.
  - SideburnsOfDoom 2y ago
    Indeed, the local optimum is in avoiding any drastic changes, which should not be made often or lightly. Switching costs and inexperience will drag you "through the valley" when making them with existing projects. I read "best" as global optimum but I know that's not the whole story. And working with like-minded colleagues on ideas such as this, is a very nice thing to have. It is something to seek out when looking for a new role.

PaulHoule 2y ago

It was the only way you could do it (reasonably) with CVS because the branching model was primitive.

SideburnsOfDoom 2y ago
Sure, far more complex branching strategies are now possible. This is a different question to "is this advisable?" Just because you can do something complex, doesn't mean you should. Avoiding this complexity can be beneficial. Yes, some of the complexity might show up somewhere else instead. But which place is the best place for it? Maybe, trunk-based development is the idea that "branching strategies are not the right place to put that complexity".

pjc50 2y ago

Slightly confused as to what is not trunk based development if TBD can include branches.

SideburnsOfDoom 2y ago
I am of the opinion that raising a pull request (which is a kind of branch) off main, then getting review, approval and a merge within an hour counts as trunk based development. But if there are long-lived branches, or a "release branch" which means that main is not what is deployed to production, or that main/"the trunk" is not what is merged onto, then you are definitely not doing trunk based development.

SideburnsOfDoom 2y ago

> doing small short-lived branches of coherent chunks takes practice but it’s very possible. Indeed, chunking and sequencing changes is a learnable skill, like many other things such as system design, effective unit tests, or writing code that compiles in the first place. Out of those it's not the hardest - it's hardly like learning a new programming language - and it is very beneficial.