this post was submitted on 03 Jul 2023
37 points (93.0% liked)
Programming
17691 readers
138 users here now
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
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I disagree with a lot of the premises presented. Not that I think trunk based itself is good/bad or anything, but some of the arguments don't convince me.
(All emphasis is mine, I didn't copy the author's because I'm lazy and on mobile lol.)
[...] This is literally "Continuous Integration (CI)", as originally suggested by the practices of Extreme Programming. While these days we tend to mean "run your build and tests on a team server every time you commit" when we say CI, what CI really meant was actually integrate your code regularly. Code living on separate branches is, by definition, not integrated. [...]
I don't disagree with anything here, I only quote it because arguments where each side is using different definitions are pointless. The author is using a different definition of CI than what most developers would use so I wanted to make sure it is mentioned.
The author sort of seems to use a different version of the term codebase in the emphasis but that just seems to be an extension of their view on what CI means. I would say my codebase is stable if the main branch is stable. They maybe seem to include branching developers' unmerged code as part of the codebase but I'm unsure.
This is the part is disagree with the most. It is trivial nowadays to not allow a branch to merge unless a build passes and it is also trivial to have that be a build of the would-be merged code as opposed to the code on the branch. Now to be fair, I believe you could also do this with a trunk approach. You could have some hook which rejects commits, but that might be too slow. Instead you could do something like have a main and stable branch and push to main but pull from stable to deploy. Then have a process that checks each commit of main for the build passing and advances stable branch forward one commit.
In short, I disagree that in a branching environment it is difficult to keep the build passing. (I agree that CI is more difficult with their definition of CI though.) The build failing should never be a surprise with either approach (apart from crazy weird edge cases that would effect both approaches). If it is inconvenient (or impossible) to run the build locally that should be addressed and I believe the author would agree with me (mentioning tests they seem to encourage unit testing), but they're seeming to say it is impossible so maybe they have a point I misunderstand.
I see no reason why the trunk based approach encourages tests and the branch based approach discourages them. I see no reason why someone trying to ignore their responsibilities of writing tests is more likely to do it for big changes than small changes because they're still making more small changes. So if they're only writing like 50% of the tests they should I don't see why it wouldn't manifest as them skipping tests on half of their commits.
I spoke on this above, but it is easy to have your CI server build a potential merge rather than the branch itself.
Like I said at the start, I'm not saying anything about trunk based development as a whole, I just disagree with some of the arguments they claim make trunk based superior.
My understanding of trunk based development is that it allows for short lived branches and keeps longer work behind feature flags as it is merged in pieces. The common CI approach with pull/merge requests having to pass tests still applies.
That isn't what the author describes, but I agree there are multiple interpretations.