The last three posts on code review workflows show that there's more than one way to do a code review, and that the approach you take will depend upon what you want to achieve with your reviews and the type of team you're working with. In this post, we'll cover how Upsource aims to make your workflow, whatever it looks like, simpler by automating as much of it as possible. We'll show the types of things that can be easily automated, when this might be useful, and show how to achieve it. Automatically Create Reviews If your workflow is predictable in who reviews code, you don't need to man

In the last two posts we talked a bit about how effective those approaches are for the author to learn and improve, because those two approaches focus on getting the code correct. The Design Evolution approach additionally mentions the value of the whole team seeing the evolution of the code. This third approach for code reviews puts learning at the centre of the process — the purpose is not to check if the code is correct, but to share with other developers what changes have been made. In this example, I'm assuming a slightly different approach to development. This team develops against

In the last post we covered a review process where the code review is performed after all the code is written with the goal of approving the suggested changes. If getting the design right is important to your team, then a collaborative and iterative approach may be appropriate — the code can be checked frequently while it's being built, so design feedback comes at the right time. In this example, I'm going to assume the team works using feature branches. As with anything, this approach has its supporters and detractors, but it's a reasonable model to showcase iterative code reviews. The

We've talked a lot about what to look for in a Code Review, but we haven't covered the process at all. There are many different reasons to perform code reviews in your team or organisation, and the process you choose should be driven by what you're trying to achieve with the reviews. The first example we're going to explore is Code Review as a Gateway. In this process, a developer picks up or is assigned a task, implements the code to the best of his/her ability, and when s/he's "finished", submits it for review. The reviewer checks the code and, if everything is OK, the code is merged into