background

A few days ago Audit asked each development team to take screenshots of their repository’s Sonar Analysis Report, I went to Sonarqube to have a look… Boy! All red lights. It’s a sight to behold

Of course, there are historical problems in this, because we took over the code of the European and American team halfway, and many issues are left over by old code.

We did not escape responsibility, and some of them were caused by the new code we submitted later. After two years of project accumulation, there were so many issues that it was hard to get back. Although Sonarqube would generate report in every Jenkins build, we did not take it as a hard indicator of the success or failure of build. As long as the build passes the QA test successfully! Sonar quality Gate damn it

The results of

In order to produce a decent report to audit, I had to hurry up with checkout -B quick_fix_sonar_issues and spent the whole day bringing the block and critical issues below the threshold.

Here are three pain points I realized as I prepared

  1. Some Sonar can detect the issue, can indeed avoid some potential bugs on the product
  2. Some colleagues’ mistakes in code are really low-level, but it is difficult to be found in manual code review. It is not my fault, but NOW I am cleaning up for my colleagues.
  3. Although the issue is quickly fixed, the owner of the code is not me. I may generate potential new issues in order to cater to the rule of Sonar, and going to check with the owner will increase a lot of communication costs. In addition, the owner may have quit his job

thinking

Jiong then think change! How can we improve our development process? Can Sonar analyze problems at the code development stage? Force the owner to resolve the issue before submitting the code? Well! It’s time to improve the current flawed development process!

The old development process

Let’s start with the current infrastructure:

  • Manage Source via GitHub
  • Code Review via Github Pull Request (used to use Gerrit but I called on developers not to use it because the UI was ugly)
  • Continuous integration is achieved through Jenkins
  • Code analysis through Sonarqube

The old process:

  1. When a new feature comes
  2. Owner checks out a Feature_dev_branch from the master (protected) branch
  3. After the development is complete, submit the Pull Request (PR) request to merge into the Master
  4. After the technical leader code reviews the PR and approves it, Feature_dev_branch is merged into the master.
  5. Merge trigger triggers Jenkins build automatically, Jenkins trigger Sonarqube scan generates report (generates report only)
  6. If Build is successful, package deploy and subsequent Automation Testing will be carried out
  7. Delivering QA tests

Improved development process:

  1. When a new feature comes
  2. Owner checks out a Feature_dev_branch from the master (protected) branch
  3. After the development is complete, submit the Pull Request (PR) request to merge into the Master
  4. PR automatically triggers Jenkins, Jenkins triggers Sonar to analyze the new code submitted this time
  5. Sonar will write reports and issues into Github PR in the form of comments as a hard check point
  6. The Owner commits the PR repeatedly until the analysis passes Sonar
  7. After the technical leader code reviews the PR and approves it, Feature_dev_branch is merged into the master.
  8. Merge trigger triggers Jenkins build automatically, Jenkins trigger Sonarqube scan generates report (generates report only)
  9. If Build is successful, package deploy and subsequent Automation Testing will be carried out
  10. Delivering QA tests

Added 3 steps to make new code pass sonar a hard target, nipping issue in the bud and leaving the pot ahead

Wow!!!!!! Too Cool!

Follow me through the configuration of Jenkins and Sonar

What? You don’t even know what Jenkins is? ! What the hell do you care to optimize the development process, move your bricks and write your bugs? Ahem! I suggest you forward this article to your colleague in charge of DevOps, invite him to dinner and ask him to help configure it

Jenkins needs a plugin called github Pull Request Builder

Webhooks are generated between Jenkins and Github. PR can automatically trigger Jenkins’ Build

With a little configuration of the plugin, the red line is important

Jenkins also needs a plugin called SonarQube Scanner

What it does is allow Jenkins to trigger Sonar’s analysis

With a little configuration of the plugin, the red line is important

Sonar not heard of? Sonar Server is not ready? Well, keep buying Devops dinner…

Sonarqube also needs to install a plugin called Github

Its purpose is to write the analysis of the generated report and issue back to Github PR in the form of comments when Sonar is finished

With a little configuration of the plugin, the red line is important

Next comes the Jenkins configuration project

No more nonsense, just paste the key configuration, the red line part is very important

This option can be checked in Advanced (although Dangerous). Since Github is an enterprise version, those who can raise PR have permission control. If you use the Github management code on the official website, please be careful with this option.

Sonar can only use Preview for analysis mode, preview mode won’t actually generate reports on Sonar.

Write in the last

As a developer, I think these basic tools to improve work efficiency should be mastered. Not that only Devops will use these tools. Who doesn’t like to be lazy, these are all good helpers for being lazy.

At the time of writing, there are some minor bugs with this process, such as sonar’s Preview mode analysis not being able to integrate with quality Gate, Sonar JS not being able to parse problematic JS files and so on, it’s not perfect enough. We are also working on other workaround projects to achieve 100% of the desired development process. If you have any suggestions, please leave a comment.