Code reviews with trunk based development

user_2445415 0
Viewed 2548

When doing trunk based development, all team members are (as far as I understand) supposed to push directly to Master (or main/trunk, whatever you call it). As illustrated here:

Trunk based development for a small team

Source

What I do not get about this approach, is how the code review fits in. You could of course do code reviews before merging any pull requests to Release, but I suppose that would be rather large reviews you would have to do.

Is it possible to put incoming pushes to Master on hold, until a code review is done?

Or is it necessary to make a seperate branch (perhaps one for each developer) to push to and then do code reviews when making a pull request to Master?

Update:

Assuming that you use feature branches for everything, you can of course just do the pull requests from the feature branches and code review those (as described in this post). But that requires everything to be in feature branches. And it was my understanding that part of a trunk based development was, that not everything requires a feature branch.

pull-request git
2 Answers

trunkbaseddevelopment.com has a page on code reviews, and has this to say:

In Trunk-Based Development teams, the PR should be on a short-lived feature branch and processed very quickly by reviews towards merging back to trunk/master.

https://trunkbaseddevelopment.com/continuous-review/

user_15498180

Trunk based development and continues integration have very similar requirements.

If we can achieve real continues integration, then what negative difference does it make if we group a few commits together and merge them into master via a pull request?

I worked on a FinTech product where we merged changes into master and deployed them once / week avg. This was because we didn't have real CI implemented, not enough trust in our test suite, no established ways to validate if we broke something in prod, no metrics, no feature switches etc... not much encouragement to hit the deploy button.

Then we improved the CI aspect big time, so we didn't fear deploying anymore. On its own this increased significantly the deployment and merging frequency. But the review was still mandatory for any new change. It didn't really encourage small changes, so I made it optional. Then we had reviews only for risky changes or when the PR owner asked it.

After the CI improvement this gave us a real good boost, we managed to have several merges and deploys / day with less defects.

The review is also easier for me if I can see the whole change in one place, like in a PR.

user_39415830
Related