When adopting Continuous Integration, your goal is to get the code into your version control as soon as possible so that it can be checked in and validated with the whole project: in return you get a RAG (red-amber-green) status of your change. Whenever a build is not green, it is defined as "broken" and it is the team's priority to re-establish a healthy head version of the branch by fixing the build.

Code Review helps by reducing broken builds, thanks to the ability to link the review status to a validation step, resulting in less time wasted by the development team.

The following diagram shows Continuous Integration without Code Review:

The preceding diagram shows the typical stability of the build when every commit is directly pushed to the master branch. Whenever an incorrect patch (P1) is pushed, the build fails causing the team to intervene to fix it, which results in them pushing a new patch (P2) to re-establish a green build again. The master branch will keep a record of the failure by having both P1 and P2 in the history of the master branch.

The following diagram shows Continuous Integration with Code Review:

As shown in the preceding diagram, the introduction of Code Review allows you to check the sanity of the change in isolation, without interfering with the normal integration flow of the functionalities and keeping a green build. Even if a faulty patch is uploaded (P1), it causes a build failure only in the review branch: this can be fixed as before by submitting a new amended commit (P2) that will succeed and thus will be merged into the master.

The benefits are twofold: firstly, the normal branch stability has not been impacted and secondly, the Code Review branch has allowed the pre-validation and clean-up of the code for allowing a consistent history without losing track of the review activity and the continuous integration feedback.

Whenever more than one person is looking at the code, the knowledge of the solution starts spreading among the team. Historically this was achieved by applying Pair Programming, one of the rules of Extreme Programming. The interaction between the "pair" leads to an earlier discussion on the solution from different perspectives with the result of a more shared understanding of the code base. This approach, however, is limited by time and space: the pair has to sit in front of the same desk at the same time, a condition that often is hard to achieve with distributed teams, which is a common set up with open source projects.

The following diagram shows Pair Programming versus Code Review:

Code Review, a practice of "team programming" is where the code is shared with potentially any member of the development team, each one free to look at it at different times beyond the code first edits timelines. The preceding diagram shows the difference in time, space, and people of the involvement of Pair-Programming versus Code Review.

There are two benefits introduced by this different approach:

Pair-programming however can still be used whenever a higher communication bandwidth and short turnaround of the discussion is needed, for example developing a particular complex algorithm where four focused eyes are definitely needed.

The possibility of having anyone reviewing your code allows external contributions from people with different mindsets and skill levels to share their views on the solution. All feedbacks are valuable, take for example, a Junior developer whose comment may be "I don't understand this fragment"—this is precious input and could prompt you to break the complexity and introduce much simpler statements. Stable code has to be simple to be maintainable: a piece of code that is obscure to a majority of developers would have more chances to be amended in the wrong way and thus to become a critical and unstable part of the project in the future! A different scenario is when we open up the review to external users or developers, including those that are accessing the code from a user perspective (that is API user, as in an Android open source project). External users can provide a different perspective on the solution providing input on its usability and the correctness and completeness of the associated documentation available. One of the fundamental aspects of Agile software development is to get feedback early in the process: with Code Review we can allow feedback when the code has not even been completed and even before having built and released it.

Not all programmers share the same code style, learning to read somebody else's code also means getting used to a different way of writing code and thus potentially being able to maintain it. When developers spend a significant amount of time reading other people's code, they learn not only about other parts of the project but also, consciously or not, to conform to others' coding styles.

Another more obvious way to achieve style unification is by enforcing a set of coding rules that can be defined and checked for compliance at every code build, providing an automatic negative review in case of discrepancies (Example: an open source project may require the code license to be inserted on top of each source). This type of enforcement is typically a good thing but can sometimes be seen as an additional cost or an activity that will slow down the development cycle, even if it definitely has long-terms benefits.

An indirect but effective way of achieving an agreed shared code style is to get the team just spending time reading each others code: programming languages follow the rules of natural languages, we speak and write using the same constructs of the language we hear and read every day. When a project starts with Code Review from the outset, it will naturally conform to a unique type "dialect" of language syntax shared by the developers that are working on it and reviewing it on a daily basis. It is common practice, however, to have a contributor's guide that describes the code conventions representing the "dialect" of language that has been agreed over the lifetime of the project.

Code Review has the power to trigger a complete set of new behaviors and dynamics among the developers. Some members naturally emerge and take the lead by commenting and proposing new creative solutions, suggesting easier frameworks or simpler algorithms for achieving the same goal. The review activity provides a natural selection of the more proactive members of the team by showing their value and appreciation through comments and commit approvals. A by-product of this is that less-senior developers are likely to push themselves to improve and try to keep up with the strongest members of the team.

The Code Review process can facilitate the team members engagement in a positive race to get the code reviewed and merged into the mainstream. It is a dynamic similar to the "CI Build game" where each successful or failed build had a corresponding score that was submitted to the last committed author. Turning the code quality selection into a positive race typically provides the benefit of engaging and encouraging people to achieve their best.

Code Review applied to open source projects becomes an excellent way to attract new team members and allows everyone to make a contribution. Having minimized the risk of breaking the build and blocking the project, allows even a new member of the project can try to express themselves by proposing a patch to the kernel of the project. Each member will also start learning from each other's feedback. The team itself could define an internal "members promotion" scheme within the project, granting new privileges based on the results of past contributions: the core team would then be automatically selected from the most involved developers, naturally elected and recognized by every member.

Getting code under review shuffles the cards and may facilitate the adoption of a more cooperative way of planning software development cycles. Instead of forcing each change to be committed to the target code branch, you allow a natural selection and promotion of the changes that the development team collectively has judged as useful and good enough to be submitted.

This election/selection mechanism is an important new factor to the acceptance criteria of the traditional Agile planning methodologies such as scrum, where user-stories are organized in sprints, and their completion is accounted in the daily stand-up for updating the burndown chart (see the following diagram).

The following diagram shows Sprint Burndown chart compared to Review board:

When adopting Code Review, the team may decide that a completed user-story is not ready to be committed because the solution implemented does not match the quality criteria defined by its members. The flip side of the medal is that burn-down could become less predictable , as it depends on the outcome of the reviews. The methodology that emerges influences the way scrum gets executed and often drives the teams to Kanban, where the improvements to the project come from a collectively agreed set of small changes.

With Gerrit, every user with the ability to access at least one branch of the repository in read mode and with the ability to upload a new change is known as a contributor. The philosophy behind Code Review is "getting early feedback from the team" and often there is no better feedback that just an alternative solution to the same problem: this is the reason why typically every user with read access is granted the ability to upload a change on the code.

Being a contributor does not necessarily provide that person with the ability to actually submit the code to any project branch, nor provide any guarantee that a specific change will be ever approved and merged by someone else.

There are times where changes are submitted as pure sample code (often prefixed with Request For Comments (RFC)—in their commit message) for explaining a proposal for a different implementation of an existing feature: every contribution is valuable regardless of whether the code will be effectively be used or not.

The existence of this role makes Code Review fundamentally different from the previous code analysis/inspection tools because anyone can be a contributor and provide input and value, regardless of their project history, access rights or authoritativeness about coding rules and best practices. The ability to use external contributors allows Code Review to be a fuel for innovation and project growth, especially in the open source domain.

In Gerrit every team member is typically allowed to express a score on a given change, expressed as a label + numeric value (positive, negative, or neutral). This role is known as a reviewer and can be further segmented according to the ability of the member to provide higher (positive or negative) score values to a change.

Team members and contributors are typically granted the ability to express a positive (+1) or negative (-1) review score in addition to simple comments on the code or on the entire change. Providing a score on a change should not be perceived as judging somebody else's skills: Code Review is always about exchanging opinions on code and should never be used for assessing team members' performance.

When team members become more experienced on the code and its underlying design, they start becoming a "technical authority" for the project. They are then entitled to provide more thorough feedback on the code and they will also have the ability to have the final word (either positive or negative) on a proposed change.

These members are known as committers and have the ability to provide a positive or negative score up to +2 (-2) for a change. The results of these reviews are absolute: +2 enables the code to be submitted into the main branch, while -2 represents a veto for the change not to be accepted.

Typically, the number of committers is fairly limited, in the Gerrit Code Review project there are no more than six committers. This is a role that can be earned on the basis of how many changes and reviews have been successfully performed by each member during the history of the project.

It is sometimes useful to assign one committer the duty of administering and monitoring the project, but who then has no active role in the Code Review process. This role is called the maintainer. Their main activities are the administration of the user-to-role mapping and the assignment of the access control permissions of different roles to the project branches.

If we take as example the Gerrit Code Review OpenSource project, the maintainer is Shawn Pearce, the project founder. He has a couple of committers who have been delegated the administrative roles whenever needed.

Today Gerrit is a highly customizable Code Review system and all labels and concepts mentioned so far can be tailored to a project's needs using a powerful rule engine. Every review input is generally referred to as labeling with a positive/negative score. The logic behind the score can also be customized and used in project's rules for approving/rejecting the changes.

Gerrit itself uses a set of default rules for implementing the logic described so far, but a project maintainer can create additional rules and define new templates to be used in other projects.

The configuration of customized rules is beyond the scope of this book but it is covered in a set of simple "cookbook recipes" inside the Gerrit online documentation. (See https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html)

Gerrit project is a workspace consisting of the following elements:

The following diagram shows Gerrit Code Review project elements:

A Gerrit change is a Git commit object uploaded for review and associated to its comments and scores. It is stored in the project's Git repository but it is not visible/accessible from the normal Git graph of commits, even it does start from a point on the commits graph.

In order for Gerrit to access the Git commit objects associated to its changes, it keeps the list of changes commit-ids in its own relational DB which are organized on a per project basis. Each change has its own unique ID, which is different to the underlying Git commit ID. The reason for this is due to the capability for a change to be amended with a set of different commits: the change id keeps a consistent link across all different amended commits.

The change id is stored at the bottom of the Git commit message into a field named Change-Id.

Gerrit changes include one or more patch-sets: all of the amended Git commits uploaded for review on the same change are stored as patch-sets where the last one represents the most recent code candidate to be merged.

Patch-sets are numbered, starting from 1 and incremented whenever a change is amended with another Git commit. It makes sense only to review only the latest patch-set as the previous ones are kept only for historical reasons, for allowing Reviewers to understand what's new from the latest inspection.

Gerrit uses one default Code Review label with a numeric value to allow the scoring of a patch-set during a Code Review phase.

Here are the possible values and the associated meanings:

Another common and very useful label used previously in the Android open source project is the Verified label. Since Gerrit Version 2.6 it is no longer pre-defined but it is still configurable as an additional review label with the values provided in the following table:

Submit is the action of accepting a change and requesting its incorporation into the target branch. The default set of rules for enabling a change for submission requires at a minimum a Code Review/+2.

Submitting a change does not necessarily involve the actual inclusion of it into its target branch: as Code Review happens on a forked branch it is needed to be merged or rebased to the target branch in order to be closed and incorporated.

This is the action of merging a submitted change into its target branch. It is separated from the actual submission because of the possibilities of choosing different strategies for incorporating the change.

Bear in mind that non-fast-forward merges will generate a version of the code that could potentially be different from the one under review, depending on the merge strategy configured in Gerrit. In the case of merge conflicts, the operation will be blocked and the change will remain submitted but un-merged: this will then require the change's author or one of its Reviewers to be notified of the failure, to rebase the change and submit a new patch-set for review.

Whenever a change after a series of negative or inconclusive reviews does not reach the minimum requirements for being submitted, it can be flagged as abandoned so that all the team members can avoid performing any further code review on it. This typically happens because either the author gives up in trying to amend the code or just because the change has become obsolete compared to the evolution of its target branch.

Don't forget that abandoned changes are not lost or removed from the repository, so they can potentially be restored at a later stage.