> Trunk-based development is the seemingly radical idea of a team working together on the same code base at the same time.
Seemingly radical, hm. I've never worked any other way in 20+ years.
Trunk-Based Development
11–20 of 47 posts
Re: Trunk-Based Development
#12Every time this comes up it feels like two groups of people meet where one group either thought the other didn't exist or was much smaller than it really is. It's bizarre.
Re: Trunk-Based Development
#13I'd be interested to hear from anyone with substantial experience of trunk-based development who prefers a merge workflow, and can articulate why. Comments on TBD posts are usually either TBD enthusiasts, or people who have never used TBD and think it sounds stupid.
I have worked with trunk based development aka everyone just pushing change lists to perforce. I much prefer people making pull requests because I can make sure people fix things in code review before it gets merged to master.
I do absolutely hate however when someone works for 3 months on a mega PR and drops a +8000 -5000 on my head.
Ultimately both systems can work and both can suck.
Re: Trunk-Based Development
#14Everything old is new again:
> Flickr is somewhat unique in that it uses a code repository with no branches; everything is checked into head, and head is pushed to production several times a day. This works well for bug fixes that we want to go out immediately, but presents a problem when we’re working on a new feature that takes several months to complete. How do we solve that problem? With flags and flippers!
Re: Trunk-Based Development
#15This is content marketing for a feature flagging tool called “Bucket.” I’m a big fan of trunk-based development, although I prefer its original name: continuous integration. (Sadly, that name has been coopted by tool vendors.) A better alternative to feature flags is keystone interfaces. It’s very simple: build your new feature without wiring it up to the UI (or API). Test it using automated tests that bypass the UI.…
Not that it makes a ton of difference, but technically trunk-based development refers more to the branching model, while continuous integration is a larger concept combining specific tooling, methods, branching, etc. You can do continuous integration with other branching models[1].
Unless a team tries hard to stick to strict CI, they usually end up with long-lived feature branches, long integration cycles, and clumsy, irregular deployments to irregular environments. So many teams still don't "get" CI, and end up wasting a shitload of time.
[1] https://www.martinfowler.com/articles/continuousIntegration....
Re: Trunk-Based Development
#16This looks horrible IMHO.
I agree changes to main should be kept small. But not too small. They should be coherent 'chunks' of functionality, even if they are not yet a fully working feature.
Committing to a dedicated separate branch, quite apart from protecting against fat-finger commits etc, keeps everything together, allows for easy code review of a complete, coherent change, etc.
Re: Trunk-Based Development
#17I am strongly opposed to feature flags and conditionals in the code, unless absolutely necessary. If you don't remove deprecated features/branches, your code will end up unmaintainable. If you do remove them, the removal is (in my experience) worse than dealing with merge conflicts. Version control is designed for the exact problem of having multiple implementations exist and merging them as needed. Why roll your own…
> Why roll your own obtuse version control
This is exactly it. Feature flags sounds really good until one realizes that they have all the requirements of a version control. So much that it was even a running joke at Uber that one starts building feature flag and ends up with a version control.
The cruft of feature flag also makes it really hard to understand while reading a code, there’s a combinatorial explosion.
Re: Trunk-Based Development
#18Here is an article of how my team had accomplished this with GitHub actions I posted earlier: https://blog.gregweber.info/blog/github-actions-trunk-based-...
Re: Trunk-Based Development
#19I am strongly opposed to feature flags and conditionals in the code, unless absolutely necessary. If you don't remove deprecated features/branches, your code will end up unmaintainable. If you do remove them, the removal is (in my experience) worse than dealing with merge conflicts. Version control is designed for the exact problem of having multiple implementations exist and merging them as needed. Why roll your own…
> Version control is designed for the exact problem of having multiple implementations exist and merging them as needed.
This is a common misconception! The primary purpose of version control is to answer discovery requests when the lawyers come knocking. :)
(I'm only half joking here. I do think VCS merges are generally not a good idea, for technical reasons like criss-cross merges being an issue.)
Re: Trunk-Based Development
#20I'd be interested to hear from anyone with substantial experience of trunk-based development who prefers a merge workflow, and can articulate why. Comments on TBD posts are usually either TBD enthusiasts, or people who have never used TBD and think it sounds stupid.
I have worked with trunk based development aka everyone just pushing change lists to perforce. I much prefer people making pull requests because I can make sure people fix things in code review before it gets merged to master. I do absolutely hate however when someone works for 3 months on a mega PR and drops a +8000 -5000 on my head. Ultimately both systems can work and both can suck.
I echo this. No pull requests is awful. The only time it's worked well for me is with 2 or 3 people sitting next to each other, with the same mindset and coding style.
Every other time I've seen or worked with teams doing it, their codrle is, well, bad. It "works" but it is full of stuff half-done, "we'll clean that up later" - except it's been there for 3 years. And I'm looking at it because I'vr narrowed down a production problem I was called in to debug, that turns out to be crappy error handling with terrible logging that mislead everyone on what was going on. A proper PR should have flagged that and asked for something slightly better than logging "something went wrong" in an try..catch statement that spans many hundreds of lines of code.
Small, focused PRs are good. Easy to review, code gets merged fast, conflicts are minimized. Massive PRs are bad, they are hard to review (problems get missed) and slow to get approved. If they get reverted because of a problem it's a mess to fix. PRs that do multiple separate things (fix two unrelated bugs, add a feature, and reformat spacing in 30 files) are impossible.
If PRs are small and focused, the duration of time the branch is open, number of commits and the actual branching model does not matter.
Long lived branches are a pain to the author (they're who has to merge Main and resolve conflicts), but that's their choice.