Automatic Code Review with SonarQube and Jenkins Part 1/2
A good way to improve code quality is to use code review. Nevertheless, often teams recoil from code review as a peer 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. However, developers should not rely solely on an automatic process, because it is difficult to account for functional or logical aspects when solely relying on metrics and rules. A good middle ground is a combination of an automated process and a code review by a peer. An additional peer review also offers benefits such as sharing knowledge and increasing the overall code quality of the team. In addition, the automatic code review provides helpful information for the reviewers in the peer review process.
With the Cloudogu EcoSystem you can implement such a system based on SCM-Manager, Jenkins and SonarQube. The plugins mentioned in the blog post are installed automatically using the EcoSystem. In this first part, we will show you how to carry out peer reviews in SCM-Manager and how to configure Jenkins. The second part will be about extending the system by integrating SonarQube. Hint: In principle, SCM-Manager offers the option of a purely automatic code review, but this is not recommended.
Code reviews by peers with SCM-Manager
In order to be able to create and work with pull requests, thus effectively collaborating with other developers, the review plugin needs to be installed. The plugin allows you to create and modify pull requests. A pull request can be created either with the command line or directly within SCM-Manager. The pull requests are a great way to inform other developers that the code is ready for review while also containing all relevant information for the reviewer in one place. Reviewers can be added to the pull request manually or configured as default reviewers in the pull request settings, which are then entered as reviewers in new pull requests. Reviewers can be informed about the status of the pull requests (creation, changes, etc.) via email. Reviewers can then comment on the pull request and either merge or reject the pull requests depending on the outcome of the review. There are also many customization options to individualize the review process for every team workflow, such as default tasks, labels, merge commit templating and so on.
In addition, the CI Plugin can be used to connect continuous integration systems to SCM-Manager and display them in the pull request. This provides the possibility to combine peer reviews with automated reviews such as Jenkins and SonarQube as they are triggered with the creation of a pull request or a new commit pushed to an existing pull request. The results are displayed directly in the pull request in the analysis status bar and can be taken into account by the reviewers. Additional rules, such as the number of approvals, can also be enforced and displayed on the pull request in the workflow status bar.
Code reviews based on Jenkins and SonarQube
The automated code review system is designed to provide feedback quickly after a push to an existing pull request or after the creation of a new PR. 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 main branch. In this system each developer uses their own branch for their changes and only if there is no violation (i.e. the project can be build) the modifications can be merged by the reviewer into the integration branch by simply clicking the respective button.
After a push to the repository, SCM-Manager invokes a build in Jenkins. Jenkins in turn merges the changes from the developer's branch into the main branch and builds the project. The status of the build will be displayed at the pull request. Developers are thus informed whether there were problems and the code needs to be revised or whether the PR can already be merged.
The automated code review system can be used for Git and Mercurial as well as Subversion repositories.
Implementation for SCM-Manager and Jenkins
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
To realise the communication between SCM-Manager and Jenkins, the CI plugin as well as the Jenkins plugin needs to be installed and Jenkins should have the SCM-Manager plugin installed.
In SCM-Manager itself, the Jenkins server can be configured globally in the settings under the Administration tab as well as per repository.
After this configuration is done, SCM-Manager is prepared for the automated code review process.
Jenkins Configuration
Jobs in Jenkins can be configured either via the user interface or via a Jenkinsfile. This can consist of a build trigger, the actual build, the configuration of the code analysis and the deployment.
A new Jenkins job can be created under New item in the menu bar on the left. So that communication between SCM-Manager and Jenkins in the form of CI status functions optimally, either Multibranch Pipeline or Organizational Folder should be selected and configured as needed. In the Multibranch Pipeline, the source of the branches can be selected under Branch Sources, in the Organizational Folder there is a corresponding setting under Project Sources. For all other project types, it is not possible to display the build status on the PR "out of the box".
That's it for the basic configuration of Jenkins to implement the automated code review.
SonarQube is next
This configuration of SCM-Manager and Jenkins provides the developer with feedback about the changes he made and the main branch gets protected from build breaking 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 main branch. The necessary configuration we will show in the second part of this post.
Tags