Repository navigation
why-i-prefer-trunk-based-development #413
Replies: 12 comments
|
Originally posted by Martin Filteau on June 24, 2023 in Foojay.io Discussions. How would you reconcile code reviews (which usually happen on a pull request) with trunk based développement? |
|
Originally posted by Brian on June 24, 2023 in Foojay.io Discussions. Most of the issues come from long lived isolated branches, so prefer a middle ground in micro branches. Branches are only allowed the live for days before they must be merged and a new branch started. This ensures frequent merged and development with the latest changes for others, while also allowing all the structured goodness of fully integrated test before merging to main for a stable main branch. |
|
Originally posted by Ed Kolis on June 25, 2023 in Foojay.io Discussions. The problem I see with this is, how do you avoid accidently breaking the code for *everyone* with one erroneous commit? With a branching model (and appropriate division of labor) you won’t risk stomping on the whole team’s toes every time you commit code. |
|
Originally posted by Martin Ledoux on June 25, 2023 in Foojay.io Discussions. You made a lot of good points. Good habits with branching can lead to the same results. GitHub PRs even encourage updating your branch from the trunk regularly, and lets you know when there are conflicts so that you can resolve them immediately. Even with trunk based development, you’ve still got to pull regularly, and sometimes stash and resolve conflict. This is one area that isn’t a real difference. Anyone coding for a week without pulling, merging or updating has a teamwork problem, and that’s a team or management issue. I don’t know, I feel that these tools and practices can lead to similar results, and this argument feels outdated – like it was written before GitHub, GitLab, etc… Good point about competing and racing to commit first. |
|
Originally posted by Karl on June 25, 2023 in Foojay.io Discussions. I develop for fun by myself, but I’m not quite sure how I would handle breaking changes that require less of changes to not break. |
|
Originally posted by James Grayson on June 25, 2023 in Foojay.io Discussions. Trunk based works well for small teams that all work together on one feature. But it does not scale. The biggest problem I’ve found with it is the heroics required when a breaking cheng went in and now the whole team can’t work. There are a number of reasons git has been winning out, mainly the derisking and code isolation as you mentioned, if used properly it can encourage better review practices and team collaboration. Enevitably you will need a longer branch to do experiments, as your team grows I would encourage you to reevaluate your position. |
|
Originally posted by Phil Day on June 25, 2023 in Foojay.io Discussions. I’ve used both, and in my experience branch based givrs much better stability of trunk. Divergance of branches can be avoided by developers taking responsibility to rebate often. Everything else, small commutes, etc, good collaboration, can be done in a branch model |
|
Originally posted by Stephen Brown on June 25, 2023 in Foojay.io Discussions. Pair programming and reviews and no PR? |
|
Originally posted by Rob on June 25, 2023 in Foojay.io Discussions. No. You negate so many other issues and things that must be accounted for. Migrations, infrastructure Improvements, a change in feature priorities. This does not encourage smaller code commits. Why do you think that? Because the developers we’ll be scared to push code? This doesn’t work in the real world with teams greater than 2 people. |
|
Originally posted by Tamás Balog on June 25, 2023 in Foojay.io Discussions. I’m curious how would you handle code reverting due to changing customer/business priorities. Let’s say the majority of a larger feature is already integrated into trunk, then the customer decides that that feature is needed in a very different way, or not at all. It seems to me that in these particular cases it can create tech debt overhead (or even unused code) and a challenge to revert many already integrated commits, instead of simply not merging a feature branch to trunk/master. |
|
Originally posted by Trisha Gee on June 26, 2023 in Foojay.io Discussions. Code reviews are often misunderstood. We think they’re there to improve the quality of the code, and yet so few developers actually know what they’re supposed to be looking for in a code review that I would argue they often just get in the way of deploying working features. I have written about anti-patterns in code reviews (and what to do about them) https://blogs.oracle.com/javamagazine/post/five-code-review-antipatterns and I have also written about how to use different styles of code reviews depending on your goals, which includes some that work for trunk-based development: https://www.jetbrains.com/help/upsource/code-review-practices.html#process In terms of the practices that need to be applied to make trunk based development work, feature toggles are an important thing, as is the ability for ANYONE to revert a commit that breaks the build, regardless of whether they worked on that code, in order for the team to continue working. The team cannot down tools and stop working because someone broke the build. The commit needs to be rolled back/reverted and then the developer(s) needs to fix it before recommitting. |
|
Originally posted by Jack German on June 26, 2023 in Foojay.io Discussions. Git allows for a trunk-like development (Gerrit is a great example). Trunk based tools do not allow easy branching. It’s not about trunk or distributed. It’s about Git being a much more comfortable tool to work with. |
Uh oh!
There was an error while loading. Please reload this page.
why-i-prefer-trunk-based-development
https://foojay.io/today/why-i-prefer-trunk-based-development/
Comments below were imported from the previous foojay.io WordPress site.
All reactions