Hi Tyler, I recently listened to a podcast you were in from React Roundup :D
Fully agree with your list of best practices for speeding up code reviews. I havent personally used PR review apps yet, so I will give that a try!
As a side note, I find that internal PR response time also has to depend on what kind of branching strategy a team is using. For example, with some branching strategies you get a lot of merge conflicts if a PR is open for too long. Obviously we'd want to change the branching strategy to something more sensible, but unfortunately it's not always possible to convince the team :(
Thanks Rense! That's awesome you heard the React Round Up podcast interview.
PR review apps are amazing! I'd highly recommend using them. There are plenty of good options depending on your codebase's infrastructure, but I've used review apps with Heroku, GitLab, and Render in the past, and they've all been great.
That's a great callout on the branching strategy. Long-lived feature branches are the worst, exactly for the reason you outlined: merge conflicts. I'm a big fan of using trunk-based development and merging often to reduce the amount of conflicts that build up over time. Feature flags help a bunch with that since you can merge code into the master branch even before it's ready to be enabled in production.
This is a great resource from Atlassian as well, and they cover some of the differences between trunk-based development and Gitflow: atlassian.com/continuous-delivery/...
I hope this helps!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Tyler, I recently listened to a podcast you were in from React Roundup :D
Fully agree with your list of best practices for speeding up code reviews. I havent personally used PR review apps yet, so I will give that a try!
As a side note, I find that internal PR response time also has to depend on what kind of branching strategy a team is using. For example, with some branching strategies you get a lot of merge conflicts if a PR is open for too long. Obviously we'd want to change the branching strategy to something more sensible, but unfortunately it's not always possible to convince the team :(
Thanks Rense! That's awesome you heard the React Round Up podcast interview.
PR review apps are amazing! I'd highly recommend using them. There are plenty of good options depending on your codebase's infrastructure, but I've used review apps with Heroku, GitLab, and Render in the past, and they've all been great.
That's a great callout on the branching strategy. Long-lived feature branches are the worst, exactly for the reason you outlined: merge conflicts. I'm a big fan of using trunk-based development and merging often to reduce the amount of conflicts that build up over time. Feature flags help a bunch with that since you can merge code into the master branch even before it's ready to be enabled in production.
Thanks for reading and for your comment!
Hmm I'm still working on understanding how trunk based strategy is supposed to work, i come from gitflow myself. Any articles you could recommend?
Here is something about trunk based strategy: trunkbaseddevelopment.com/
It is quite frightened at the beginning, but it is also a great experience for the future.
This is a great resource from Atlassian as well, and they cover some of the differences between trunk-based development and Gitflow: atlassian.com/continuous-delivery/...
I hope this helps!