How do you do code reviews with this model?
Trunk-Based Development
31–40 of 47 posts
Re: Trunk-Based Development
#32Everything 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! https…
The Flickr team was really innovative and the industry as a whole learned a lot from them. Perhaps some of that wisdom has been lost on the next generation of developers and now it's being packaged and sold to them.
Re: Trunk-Based Development
#33I 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…
There are tools that exist to clean up old flags, but of course you need to know they should be retired (if always off)or integrated into the baseline code (if always on)
Re: Trunk-Based Development
#34How do you do code reviews with this model?
It’s in the post :)
> In practice, many teams will use a pull request-based workflow because the tests could be too complicated to run locally or need to facilitate code reviews. For trunk-based development to fulfill its promise, it’s imperative that pull requests are kept small and that the team is committed to reviewing them quickly.
Re: Trunk-Based Development
#35Every 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.
Agreed! It’s apparently a divisive topic.
Re: Trunk-Based Development
#36[deleted]
Re: Trunk-Based Development
#37Earlier quoted context omitted.
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…
The article you referenced specifically says that “trunk-based development” is a synonym for “continuous integration.” Please see the section titled “What is the difference between continuous integration and trunk-based development?”
Martin's only saying that because the idea of CI came first, and he "doesn't want to rudely erase the work of Kent Beck". Trunk-based development has the branching model in the name. CI doesn't; it refers to a method to integrate code, and a whole lot of practices, tools, etc.
In practice, most people don't even use the trunk model for their CI. Most people use feature branches and PRs. They still use everything else from CI, except for the single-branch. What should we call that, then? Not-quite-CI CI? It's simpler to refer to the general idea as "CI", even if it doesn't use a single branch. If you want to refer to the strict single-branch method, "trunk-based development" makes it clear.
Re: Trunk-Based Development
#38I’m gonna be honest, this sounds horrible. If you do adopt this though, why even use Git? Why not use Perforce or something?
As someone who uses this model with git, the main reason is because git is ubiquitous but I cannot get used to git's incredibly user unfriendly API. I've tried the feature branch approach and it doesn't click for me. Merge conflicts, lost changes, and git reset everywhere. So in other words, I'm using this model because if I could use perforce I probably would, but git is everywhere. Also, every time I bring up git's…
With jujutsu I think is very close to allow this kind of stuff. I like branches because some of my work truly benefit from slow cooking, but with jj I'm more linear than before.
Re: Trunk-Based Development
#39It is really sad that almost no modern code review tools support trunk-based development. Nearly all tools assume some kind of branching/pull request.
One tool that was great for _both_ use cases was Jetbrains Upsource, where you could just string a bunch of related commits together in one review. Better yet, it could recognize based on the commit message (like workitem or CR number) that a commit belongs to the same code review and add it.
We actually still use it, even though Jetbrains canned it, because we have found no good alternative. Some of the tools that do code review mandate to also host the code within it, which is not an option because we already host the code in a system we’re happy with.
Re: Trunk-Based Development
#40How do you do code reviews with this model?
It’s in the post :) > In practice, many teams will use a pull request-based workflow because the tests could be too complicated to run locally or need to facilitate code reviews. For trunk-based development to fulfill its promise, it’s imperative that pull requests are kept small and that the team is committed to reviewing them quickly.
Then it is not trunk-based, it is still PR based. I would also wonder how bigger features would get developed, without littering it across multiple pull requests and feature flags to make sure the code still compiles.