36
Why I prefer trunk-based development - Trisha Gee
(trishagee.com)
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
My problem with trunk based development is I feel like people treat it as the solution to a problem that is fundamentally a developer culture problem.
This is really the main benefit of trunk based development, and it's something you can get with feature branches as well, you just have to make sure everyone on your team starts reducing scope of their features and merging in smaller and smaller features sets.
There's nothing inherit in the trunk based development model that stops someone from sitting on changes for a month, never pulling, and then trying to pull and ending up with a bunch of conflicts anyways. So it really feels like "yeah use trunk based development" boils down to "integrate continuously" which can be done with a branching model.
And I work at a company who switched to “trunk-based development” but because of bureaucracy, nothing can be merged early. Big feature branches still sit waiting for months, then need a big document describing the changes and their impact, some QA team to test the new feature branch build etc. The “release management” team simply renamed the develop branch to trunk and called it trunk-based development.