background
A while back, Audit in the US required each development team to screenshot their Own Sonar Analysis Report on Their Repository. I went to Sonarqube to have a look… Good boy! It was all red lights. It was horrible
Of course, there is a historical problem in this, because we took over the code of the European and American teams halfway, and many issues are left by the old code.
I don’t shirk my responsibilities, but some of them are caused by the new code we submitted later. After two years of project accumulation, the issue has accumulated a little too much and it is hard to return. Although Sonarqube generated a report in each Jenkins build, we did not take it as a hard indicator of the success or failure of the build. As long as the build successfully passes the QA tests! Sonar damn quality gate
The results of
In order to produce a decent and beautiful report to the audit, I had to execute checkout -b quick_fix_sonar_issues quickly and spend a whole day to reduce the block and critical issues below the threshold.
I experienced the following three pain points
- Many of the issues that Sonar can detect are actually very difficult to detect with manual code review GitHub PR
- The mistakes made by some colleagues in the code are really low-level, but they are hard to be found in the manual code review. It is not my fault, but NOW I am cleaning up for my colleagues.
- Although I quickly fix the issue, I am not the owner of the code. I may produce a potential new issue in order to cater to the rule of Sonar, and checking with the owner one by one will increase a lot of communication costs. In addition, the owner may have left the company
thinking
Jiong is thinking of change! How can we improve our development process? Having Sonar analyze problems while the code is in development? Forcing the owner to resolve the issue before submitting the code? Well! It is time to improve the current flawed development process!
The old development process
Let’s start with the current infrastructure:
- Manage the source via GitHub
- – Implement Code Review via Github Pull Request (used gerrit but I’m urging developers to reject it because the UI is too ugly)
- Jenkins for continuous integration
- Code analysis with Sonarqube (dummy)
The old process:
- When a new feature comes
- The owner checks out a feature_dev_branch for development from the master (protected) branch
- When development is complete, submit the Pull Request (PR) request to be merged into the Master
- After the technical leader reviews and approves the PR, feature_dev_branch is merged into the master.
- Merge triggers Jenkins to automatically build, Jenkins triggers Sonarqube Scan to generate report (generates report only)
- If the Build is successful, package deploy and subsequent Automation Testing will be carried out
- Deliver QA tests
Improved development process:
- When a new feature comes
- The owner checks out a feature_dev_branch for development from the master (protected) branch
- When development is complete, submit the Pull Request (PR) request to be merged into the Master
- PR automatically triggers Jenkins, Jenkins triggers Sonar to analyze the submitted new code
- Sonar writes reports and issues as comments to Github PR as hard check points
- The Owner commits the PR repeatedly until it is analyzed through Sonar
- After the technical leader reviews and approves the PR, feature_dev_branch is merged into the master.
- Merge triggers Jenkins to automatically build, Jenkins triggers Sonarqube Scan to generate report (generates report only)
- If the Build is successful, package deploy and subsequent Automation Testing will be carried out
- Deliver QA tests
Add 3 steps, make new code detection through Sonar become a hard indicator, nip the issue in the bud, put the pot in front
Wow!!!!!! Too Cool!
Follow me step by step to complete the configuration of Jenkins and Sonar
What? You don’t even know what Jenkins is? ! Then what the hell do you care to optimize the development process, move your bricks, write your bugs! Ahem! I suggest you forward this to your DevOps colleague and invite him to dinner to help configure it
Jenkins needed a plugin called Github Pull Request Builder
It is used to generate webhooks between Jenkins and Github, and similar PR can automatically trigger Jenkins Build
Configure the plugin a little bit, and it’s important where the red lines are drawn
Jenkins also needed a plugin called SonarQube Scanner
What it does is it lets Jenkins trigger Sonar’s analysis
Configure the plugin a little bit, and it’s important where the red lines are drawn
Sonar you haven’t heard of? Don’t have ready-made Sonar Server? Well, keep inviting Devops to dinner…
Sonarqube (note: Sonarqube, not Jenkins) also needs to install a plugin called Github
The purpose of this is to write the generated report and issue analysis back to Github PR as comments when Sonar is done
Configure the plugin a little bit, and it’s important where the red lines are drawn
The next step is to configure Jenkins’ project
No more nonsense, just the key configuration, the red line is important
If you are using Github’s official website to manage your code, be careful to use this option. It is recommended to use a blacklist and whitelist to control the conditions that trigger.
The following is the configuration of Sonar, it is important to note that analysis mode can only be used with Preview, preview mode will not actually generate reports on Sonar.
Write in the last
As a developer, I think there are some basic productivity tools that need to be mastered. I’m not saying that devops is the only way to use these tools. Who doesn’t like to be lazy, and these are good helpers.
As of press time, there are some small bugs in this process, such as Preview mode sonar analysis can not be combined with quality Gate in Sonar, Sonar JS can not analyze parse problematic JS files and so on, it is not perfect. We are also working with other workaround to achieve 100% of the desired development process. If you have good suggestions, please leave a comment.