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 30 days 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".
pjc50 30 days 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 30 days 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.
taylodl 30 days ago [-]
> Teams need to be encouraged to "inspect and adapt".
Agree 100% and that's on excellent callout.
SideburnsOfDoom 30 days 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.
pjc50 30 days ago [-]
Slightly confused as to what is not trunk based development if TBD can include branches.
SideburnsOfDoom 30 days 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.
PaulHoule 30 days ago [-]
It was the only way you could do it (reasonably) with CVS because the branching model was primitive.
SideburnsOfDoom 30 days 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".
- 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.
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.
Agree 100% and that's on excellent callout.
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.
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.
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".