1. The background

With the rapid growth of OPPO’s Internet business and the continuous expansion of the team size, the requirements for code quality are also constantly improving. However, the existing code review tools GitLab and Gerrit have been unable to meet our review requirements, mainly highlighting the following problems:

  • Inability to efficiently review code for bugs or potential quality issues

  • Code specifications within the team are hard to follow

  • Newcomers only get so much growth from code

  • The ease of code review needs to be improved

We urgently need an efficient and concise code review tool to assist us in code review.

2. Self-research or transformation

If you only make a review tool, the lack of code management function, need to frequently switch between the code review tool and code hosting tool, user experience is not friendly.

Code review and code management are best in one system, but there are two problems with developing a tool system that combines both:

First, to realize the code review system with the function of code management, it is necessary to develop a set of relatively perfect code management system, but some code hosting platform itself has been relatively mature, and in addition, the difficulty and workload of development are relatively large.

Second, the project risk is high, and the stability and reliability of the developed system have certain challenges.

Is there a way to implement a simple Code Review solution without developing a Code management system? After in-depth investigation, we found it feasible to develop Code Review on GitLab. After several months of research and development, our Code Review system Fireeye was born in this way.

Fireeye is a code review tool developed by OPPO Internet, which integrates the review function of Gerrit and the code management function of GitLab. Its main functions include:

  • Mandatory/optional code review

  • Merge Request

  • Code warehouse Management

Fireeye has the following characteristics compared to other code review tools:

  • Review code conflict predetection

  • Flexible reviewers and rules (common and essential reviewers, with pass thresholds)

  • Flexible branch review rules (custom branches to review)

  • Support multiple collaborative development modes (including mandatory review and Merge Request modes)

  • Seamless intercommunication with instant messaging tools and email systems

3. How fire Eyes work

In order to facilitate everyone to understand the text, here is a simple introduction to the principle of fire eye. Fireeye makes use of the refs namespace feature of Git. Below is the directory structure of a Git repository stored on the server:

This structure mainly includes the following parts:

  • The hook directory stores the server-side hook scripts of the project. Pre-receive scripts will be triggered before the code is submitted to the repository, and post-receive scripts will be triggered after the code is submitted. We mainly use these two scripts.

  • The Objects directory holds all the contents of the Git database;

  • The refs directory stores Pointers for all branches to their submitted objects, each pointing to the latest CommitId for the branch or tag. The default branch is always in the refs/heads subfolder, for example the master branch we often use points to refs/heads/master.

Refs /changes/{ChangeId}/{Branch} = refs/changes/{ChangeId} Use this feature to store the Commit content for review, and when the review passes, merge refs/changes/{ChangeId}/{Branch} into the previously normal Branch. Using the dev branch as an example, the submitted model is as follows:

4. Fireeye technical architecture

The following diagram shows the current architecture of FireEye:

4.1 a clattering RPC

Fireeye RPC is a proxy service implemented by Dubbo that performs the following Git operations:

  • The code merge

  • Tags operate

  • Branch operation

  • Compare the operating

  • Commit history action

Fireeye Web calls Fireeye RPC to complete operations on the Git repository. The core of Fireeye RPC is to process the underlying data of Git by using JGit (an open source Java tool for manipulating Git). Fireeye RPC realizes all Git viewing operations on the basis of JGit, but JGit does not provide the merging method based on bare library (the form of server storing Git files). Based on the underlying atomic methods provided by JGit, we encapsulated and transformed to get the bare-library merging algorithm we wanted.

4.2 a clattering Web

Fireeye Web is a Web project that deals with the following:

  • Reviews, reviews, and status reversals

  • Setup (Reviewers/Audit rules/notifications/warehouse setup)

  • Basic warehouse management

  • GitLab permission synchronization

review

After the user submits a review, the reviewer will receive a review invitation link, which can be clicked to review. For comments, we set a status marked as resolved, which makes it easy for reviewers or review sponsors to track problems.

To make the review more complete, we have ported GitLab’s Merge Request mode and made some improvements. One particular improvement: lock commit. When the user selects a lock commit, subsequent commits of the Merge branch will not be merged in this Merge Request. We think this is important in multi-player development to ensure that the code that needs to be merged only contains the code that originated the Merge Request.

Conflict predetection

When other teams used Gerrit for review, a big pain point was to merge the code after the review process and find that the code was in conflict with the code that had been merged into the warehouse, and then they had to merge the code again and start the review process again. Fireeye specifically solves this problem, when the user does the review, the code being reviewed and the branch to be merged in memory once, if there is a conflict in the review interface prominent prompt conflict, and inform the solution to the conflict.

Basic warehouse management

Like mainstream code management tools, we provide visual manipulation of Git basic data on the interface. At present, the following functions are realized through fireeye RPC: branch management, file management, label management, submit history view, comparison and so on.

GitLab permission synchronization

We did not develop a set of authority system separately in Fireeye system, the whole system is the reuse of GitLab authority, every period of time or GitLab authority changes, Fireeye will pull GitLab authority data, mainly including: project, group, relationship between project and person, group and person.

4.3 Fireeye Git Hooks

Fireeye Git hooks are two Git server hooks implemented by fireeye system: pre-receive and post-receive. The pre-submission hook is used to reject the submission when the user selects ordinary submission and enables mandatory review. The post commit hook is used when the review code has been successfully submitted to call the Fireeye platform to generate the review task. The following diagram shows the functionality of the two hooks during code submission:

4.4 FireEye CLI

The Fireeye command line is the client command line that FireEye uses to submit reviews. The *git push HEAD:refs/changes/{ChangeId} /{Branch}* command needs to be executed if the review task needs to be submitted. This command is too long, unfriendly to users and difficult to get started. Therefore, we decide to use the client command line to simplify the submission process. And reduce the cost of use.

To make the Fireeye command line available to all platforms (Linux/Windows/Mac), the Fireeye command line is written in Go and compiled into binaries for each platform.

5. Procedure of using fire eye

Preparations: Install the Fireeye command-line interface (CLI). The steps are as follows:

  1. Write your code: As usual, git add* and commit* the code.

  2. Submit code for review: use fireeye command line to submit code, the system will feedback the code review address, and inform relevant reviewers using internal communication tools. The following figure shows the process of submitting a review and generating a task using the Fireeye command line:

  1. Code review: the code will be reviewed on fireeye platform, and the code will be automatically closed after passing the review (manual closing can be configured).

In the development process and daily development is not different, but with the fire eye submission command instead of Git submission command.

6. Future planning

6.1 Automatic Scanning

Code Review can solve the problem of business manual Review, but some Code bugs or smells can be detected in advance by Code scanning tools. Therefore, we will introduce our own automated scanning tools and embed this process in the Review process to assist the Review.

6.2 Free review

The free review mode differs from the auto-initiate review mode in that it can review any submission. This mode is suitable for scenarios where code is reviewed or reviewed after development, but does not involve merging code, such as code review meetings.

7 summary

Fireeye system is based on GitLab code submission process to do interception, existing GitLab users can use FireEye at a very low cost. The flexible review mode, diversified review rules and flexible review branch selection of Fireeye system can assist the team to do a good job in code review, and achieve the expected results of the system development.