As a Quality Consultant, I have all kinds of ‘projects’, I mean, all kind of source code analysis, for various types of processes (Continuous Integration, Quality Gate, Quality Assessment, etc.). and for all kinds of technologies. let’s remember that SonarQube is not just an Open Source tool that analyzes Java or object-oriented programming languages: it is also very useful for Legacy applications with Cobol, SAP-ABAP, client-server, etc.
So I decided to take advantage of the relative decrease in activity at the end of year to clean up my demos … starting with PL/SQL. Over time, I collected all kinds of scripts programs for database procedures, and this will be an opportunity to:
- Remember how I organize my analysis.
- Configure and realize a PL/SQL code analysis with SonarQube.
- Look at customizing the perfile of PL/SQL rules delivered with SonarQube.
I stil don’t know how many posts will be needed to cover these topics, I tend to write as it comes and I like to leave some margin for improvisation. In addition, I will probably have to stop for some New Year’s greetings (and family celebrations), so it is likely that this will take us until January.
Organization of the environment analysis
First, a few reminders on how I organized my environment. It is obviously not necessary to do the same, but I still recommend you to adopt some rules.
Especially if you work as a team. You do not want that people call you during the holidays because nobody is able to work on that code quality assessment that you have not completed due to some delay taken by the customer to deliver on time the code of his application. And the poor guy who must continue this task does not know how you used to work, how you set up a code scan, if you use some specific rules, etc.
And even if you work alone, as a freelancer for example, it remains a good thing to always follow the same process, or you could not remember where the hell you saved this configuration file of this analysis conducted 2 years ago, and that you would like to find now.
Anyway, here’s how I organize it on my laptop:
- A folder dedicated to my analysis environment ‘C:\SRC’.
- Different directories organized around different technologies (J2EE, ABAP, Cobol, Repository for other technos, …) and a folder for all my démos : ‘C:\SRC\Demo’.
- Inside this folder, a sub-directory for each demo for each technology :‘C:\SRC\Demo\J2EE’, ‘C:\SRC\Demo\Cobol’, …, and ‘C:\SRC\Demo\PLSQL’.
Inside each of these folders, I use three directories:
- ‘Delivery’ to store the versions of the application delivered for an assessment.
- ‘Conf’ to manage all configuration files, documentations, assessments, sheets, presentations, etc.
- ‘Source’ to copy the source code to be analized.
Why not have a single directory to analyze one version? First because I may have to analyze successive versions. For example, a customer wants an assessment because he is not very happy with his outsourcer and he would like to check the quality of the code provided. We will first analyze the initial version assigned for maintenance to the outsourcer, and then the final version that he has returned to the customer. By analyzing these two versions sequentially, we can determine the differences – for better or for worse – in terms of defects, complexity and maintainability between these two versions.
More importantly, sometimes I have to change the code supplied by the customer, for several reasons:
- A file causes a problem forcing the parser to stop the analysis. For example, the delivery supplied by the customer contains an old program, which is no longer used, but does not compile either.
- I have to rearrange the code differently. Amazing the number of architects who reinvented best practices in organizing packages and directories.
- The delivery contains a lot of directories ‘.svn’ filling up hard disk space, but also slowing down the analysis.
If you have a server, I recommend you use a first drive for your softwares and the more efficient hard disk to store the source code and make your analysis.
Of course, if you work within a project team, you probably have a configuration management tool (SCM) and therefore your environment will be different. Note simply that my analysis of PL/SQL will be done in : ‘C:\SRC\Demo\PLSQL\Source’.
The next post will focus on the configuration of this analysis.