Automatic Code Review Part 1/2

Home/General/Automatic Code Review Part 1/2

A good way to improve code quality is to use code review. Often teams recoil from code review because it demands a lot of time. An alternative could be an automated code review system that checks your code for compliance with certain metrics and rules. With SCM-Manager Universe you can implement such a system based on SCM-Manager, Jenkins and SonarQube. In this first part we will show you how to configure SCM-Manager and Jenkins. The second part will be about extending the system by integrating SonarQube. 

General Structure

The automated code review system is designed to provide feedback quickly after a push. It checks whether the code can be build or not as well as for the success of unit tests. By integrating SonarQube you can define individual rules and metrics that need to be met in order to save changes to the master branch. In this system each developer uses his own branch for his changes and only if there is no violation (i.e the project can be build) the modifications are merged to the master branch.

codeReviewProcess

After a push to the repository SCM-Manager invokes a build in Jenkins. Jenkins in turn merges the changes from the developer branch into the master branch and builds the project. If there are no problems during the build, Jenkins publishes the merged master branch to the central repository in SCM-Manager. If there are problems merge doesn't get published. The developer gets the information that there was a problem during the build from Jenkins and the code needs to be modified to be published.

The automated code review system can be used for Git and Mercurial repositories.

Implementation

To implement this automatic code review process it is necessary to adjust the configuration of SCM-Manager and Jenkins in some places.

SCM-Manager Configuration

Because the automated code review is based on individual development branches for each developer it is necessary to install the scm-branchwp-plugin. After the installation of the plugin and the restart of SCM-Manager you can start granting permissions to the repository and branches:

  1. Each developer needs write permissions to the repository in the Permissions tab.
  2. Add permissions to the branches in the Branch Write Protection tab.
    1. The user that is configured in the Jenkins tab needs access to the master branch.
    2. Each developer needs access to his own development branch.
      Hint: It isn't necessary to add each user individually. You can use a group for all developers and a variable, e.g. username.

scmmuConf

After this configuration is done, SCM-Manager is prepared for the automated code review process.

Jenkins Configuration

The necessary adjustments to the project configuration in Jenkins is done in the Configure screen of each project. Basically you have to perform three modifications:

  1. Enter the development branches with wildcards for the usernames in the Branches to build field.
  2. Click on Advanced beneath Branches to build, check the box Merge before build and enter master as Branch to merge to.
  3. Add Git Publisher as Post-build Action to the project and select the two checkboxes.
    Hint: Git Publisher should be placed above Sonar as Post-build Action.

jenkinsConf

 That's it for the basic configuration of Jenkins to implement the automated code review.

Conclusion

This configuration of SCM-Manager and Jenkins provides the developer with feedback about the changes he made and the master branch gets protected from build braking changes. It is possible to extend the automated code review by adding metrics of the SonarQube analysis as a requirement that needs to be met to merge changes to the master branch. The necessary configuration we will show in the second part of this post.

 

With kind regards,

your SCM-Manager Universe Team

 

Proceed to part 2.

2 Responses to “Automatic Code Review Part 1/2”

written by Michael Augustin On 15 October 2014 Reply

Thanks for this description. Is it possible to have this process with mercurial too, because we develop with TortoiseHG-clients? In SCM-Manager this should be exactly the same, but how about the configuration in jenkins? Do you have a solution for this?

Kind regards,
Michael

written by SCM-Support On 15 October 2014 Reply

Hi Michael,
it should be possible to implement the process for Hg, but it is more complicated. The Jenkins-Mercurial plugin doesn’t support the same features like the git plugin, therefore it’s a bit inconvenient. Let me try to give you a short explanation of how it should work:
1. You need the Parameterized Trigger Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin).
2. You need one job for each developer.
3. You need a job for the master branch (free-style project).
4. The developer jobs need a post build action “Build other projects” to trigger the job for the master branch.
5. The master branch needs the build option “Execute Shell” with the following two commands to publish the changes:
a. hg merge $DEVELOPER_BRANCH
b. hg push

Hopefully this explanation helps you.

Best regards,
Daniel, SCM-Manager Universe Team

Leave a Comment