Last post in our series on the analysis of the quality of PL/SQL code with SonarQube.

Assessing the quality of an application is not just doing a code analysis: anyone can do that. The work of a Quality consultant is based on answering the following questions: what, why, how, how much.

• What: analyze the results. Size, complexity and duplications, this is what we have seen in our previous posts. We examine the overall figures but also the average and the variance, as well as trends over time when there are several versions. Then we look at the main violations of best practices, focusing primarily on Blockers and Criticals.
• Why these results: investigating the causes of the analyzed measures, searching for the origin of the results.
• How to remedy: propose a plan of action. In fact, make several proposals. We shall see below that I propose different plans for the short, medium and long term.
• How much it costs : assessing the cost of each plan. Continue reading →

Sorry to keep you waiting for the following of this series on PL/SQL code and SonarQube, but I was pretty busy between, work and my laptop who suddenly decided to abandon me, of course invoking the Murphy’s law to justify breaking down at the worst time.

In the previous posts: after configuring an analysis of PL/SQL code with SonarQube, we defined our own Quality Profile by directing Blockers and Criticals rules on robustness, performance and security. What looks like our dashboard now?

Continue reading →

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 →

After configuring our first PL/SQL analysis from Jenkins, we launched it, so we can now look at the results in the SonarQube dashboard.

This will be an opportunity to discuss and explain, in our next posts, the PL/SQL best practices proposed by SonarQube. But first, let’s have a look at the rules we get with the SonarQube PL/SQL Quality Profile. Continue reading →

In the first post of this new series about analysis of PL/SQL code with SonarQube, we have seen how I organize my analysis environment, with:

• a folder C:\SRC\ with all my projects,
• a sub-directory dedicated to each project,
• different other sub-directories, including one ‘..\Source’ containing the source code to be analyzed.

In the case of our PL/SQL analysis, this will therefoe be placed in the folder ’C:\SRC\Demo\PLSQL\Source’.

Let’s see no how to create and configure a SonarQube analysis of this code, with Jenkins. Continue reading →

Now that I have update my source code analysis environment, with the upgrades of SonarQube,or  SonarQube-Runner and Jenkins, time has come to update also mi repository of aplicactions and demos. Continue reading →