A post as a synthesis for this series on the analysis of PL/SQL code with SonarQube.

After configuring our analysis with Jenkins, we launched it and found 17 Blockers but zero critical defects (Criticals) with the default SonarQube Quality Profile. In fact, the 5 existing Critical rules were disabled and some other rules of different criticalities too: 58 out of 132.
Continue reading →

We continue this series on the analysis of PL/ SQL code with today, the Major rules.

We saw previously how to organize our environment and configure our code analysis with Jenkins and SonarQube.

We created our own Quality Profile and reviewed the Blockers and the Criticals, all oriented toward Reliability and Security. Continue reading →

In the previous post in this series on the analysis of PL/SQL code with SonarQube, we reviewed the existing Blockers rules in our Quality Profile.

We found three violations of PL/SQL programming best practices whose consequences are so significant that no tolerance can be allowed for them. Which therefore justifies their status of ‘blockers‘.

We also found a total of 18 defects for these 3 rules, so with this rather low number, let’s assume that these rules are known by the project team.

Finally, these defects have resulted in a logical bug in the application – an operation that will never be performed because the corresponding condition will never be met – or even a possible crash. Continue reading →

In the previous post, we have seen how to create our own PL/SQL Quality Profile activating all the 132 existing rules in the SonarQube default profile. Now, we can relaunch the analysis initiated earlier.

This way, I will be able to work with all the rules existing in the PL/SQL profile and select the ones that I want to use in order to create a PL/SQL dashboard for my demo environment. Continue reading →