Get the Runner here
Grab the Soure code
Get the Runner here
SonarQube 3.6.3 + Maven 2.0.11 + PostgreSQL
STEP 1: Make sure postgres binaries are available in your PATH.
STEP 2: Initialize postgres db, execute the following command
initdb -D datapath
STEP 3: Start the database, execute the following command
pg_ctl start -l “E:\logs\postgres\sonar.log” -D “E:\data\postgres\sonar”
STEP 4: Verify that postgres is listening on the default port (5432)
netstat -aon | findstr 127.0.0.1:5432
STEP 5: Set up the sonar database
Create user postgres, and database sonar, by executing the following command
createuser -s -r postgres
connect to sonar databaseas, by executing the following command
Create user sonar and grant all the permissions, as sonar will create tables/indexes/constraints for you, by executing the following command
create user sonar with password ‘sonar’;
grant all on database sonar to sonar;
Download SonarQube 3.6.3, Version 3.6.3 is compatible with Maven 2.0.11
STEP 1: disable the default H2 database by commenting the line number 48 of SONAR_HOME/conf/sonar.properties
STEP 2: Enable postgres database by un commenting the line number 86 of SONAR_HOME/conf/sonar.properties
Goto SONAR_HOME/bin, and based on the OS, go to the corresponding subdirectory, in my case it is windows-x86-64, so the full path would be SONAR_HOME/bin/ windows-x86-64
Double click on StartSonar.bat
First time you would see lots of output, as it will create tables/indexes/constraints etc.
and finally you will see something like this, as you can see that the application has started on port 9000
If you list out all tables in the current database, by executing \dt command in psql, you will get something like this
Point your browser to http://localhost:9000/
SonarQube is up and running now.
Since software development has started, there has been a chaos and people always ask “Is it done right?“, and we get a mix of answers
How do we evaluate the quality of the code and the developer who has written the code? It is easy enough to evaluate factory worker ( what is produced with acceptable quality), lawyer (cases won) etc.
Well it can be answered if we can measure software quality. Software quality can be defined easily through abstractions, examining it from different perspectives and rating it along different dimensions
Let’s put ourselves into a test, let’s see if we can read this.
I cdnuolt blveiee taht I cluod aculaclty uesdnatnrd waht I was rdgnieg. The phaonmneal pweor of the hmuan mnid. It deosn’t mttaer in waht oredr the leteerrs in a wrod are, the olny iprmoatnt tihng is taht the frist and lsat ltteer be in the rghit pclae. The rset can be a taotl msess and you can sitll raed it wouthit a porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe.
The preceding text does not contain one single word spelled correctly but proves to be readable. From a product perspective, someone could support that although the text is flawed it does the job, since it manages to remain understandable. But this has the side effect of deteriorating the final reading experience, requiring additional effort to reconstruct the words and phrases. The reader unconsciously stresses his mind in an effort to adapt and decipher the messed-up words. On the other hand, the editor assigned to improve or add to the text would have to cope with this non-standard writing practice delaying the whole process.
Switch the corrupt text for a software product’s source code. The reader is now the end user of the product and the editor the developer. They both experience product quality differently, each one from their own views. The end user from a functional perspective while the developer from a structural one.
Software quality measurement is a quantitative process summing up weighted attribute values, which in part describe specific software characteristics. For each characteristic, a set of such measurable attributes is defined.
Now the question is, what are software characteristics? Well it could be:
How do we define the corresponding attributes?
After having the software characteristics defined, the next question which comes to our mind is how do we enforce it automatically? The answer lies in static code analysis
Static Code Analysis
Static code analysis is a collection of algorithms and techniques used to analyze source code in order to automatically find potential errors or poor coding practices. The idea is similar in spirit to compiler warnings (which can be useful for finding coding errors) but to take that idea a step further and find bugs that are traditionally found using run-time debugging techniques such as testing.
Static code analysis, also commonly called “white-box” testing, looks at applications in non-runtime environment. It is the only proven method to cover the entire code base and identify all the vulnerable patterns. Static code analysis is also considered as a way to automate code review process.
The tasks solved by static code analysis software can be divided into 3 categories:
There are many static analysis tools available. However, Checkstyle, PMD, and FindBugs are well known and used in most of the projects
Checkstyle is an open source tool that can help enforce coding standards and best practices, with a particular focus on coding conventions. Although Checkstyle does cover some static code analysis features (In much the same way as PMD and Findbug), however we will mainly concentrate on Detecting and Enforcing Coding Conventions with Checkstyle.
Main Focus : Conventions
PMD is a static code analysis tool, capable of automatically detecting a wide range of potential defects and unsafe or non optimized code (bad practices). Whereas other tools, such as Checkstyle, can verify that coding conventions and standards are respected, PMD focuses more on preemptive defect detection (ensure good practices are followed). It comes with a rich and highly configurable set of rules, and you can easily configure which particular rules should be used for a given project.
The bad practices type consists of well known behaviors that almost systematically lead to difficulties over time. Here are a few examples of bad practices:
Main Focus : Bad practices
Findbug is another static analysis tool for Java, similar in some ways to Checkstyle and PMD, but with a quite different focus. Findbug is not concerned by formatting or coding standards and only marginally interested in best practices: in fact, it concentrates on detecting potential bugs and performance issues. It does a very good job of finding these, and can detect many types of common, hard-to-find bugs. Indeed, Findbug is capable of detecting quite a different set of issues than PMD or Checkstyle with a relatively high degree of precision. As such, it can be a useful addition to your static analysis toolbox.
Main Focus : Potential Bugs
As per the HP Fortify website,
HP Fortify Static Code Analyzer helps verify that your software is trustworthy, reduce costs, increase productivity and implement secure coding best practices ……
Main Focus : Security Vulnerabilities
Sonar collects and analyzes source code, measuring quality and providing reports for your projects. It combines static and dynamic analysis tools and enables quality to be measured continuously over time. Everything that affects our code base, from minor styling details to critical design errors, is inspected and evaluated by Sonar thereby enabling developers to access and track code analysis data ranging from styling errors, potential bugs, and code defects to design inefficiencies, code duplication, lack of test coverage, and excess complexity. The Sonar platform analyzes source code from different aspects and hence it drills down to your code layer by layer, moving from module level down to class level. At each level Sonar produces metric values and statistics, revealing problematic areas in the source that require inspection or improvement.
Main Focus : Each dimension from different perspective utilizing Checkstyle, PMD, Findbug, Fortify and many other static/dynamic code analysis tools
You may wonder if sonarQube uses existing proven tools then why use it at all? You can just configure these tools as a plugin in the CI server and bang we will be done. Well not necessarily, well there are lots of caveats.
What makes Sonar really stand out is that it not only provides metrics and statistics about your code but translates these nondescript values to real business values such as risk and technical debt. Sonar not only addresses to core developers and programmers but to project managers and even higher managerial levels as well, due to the management aspect it offers. This concept is strengthened more by Sonar’s enhanced reporting capabilities and multiple views addressing source code from different perspectives.
From a managerial perspective, transparent and continuous access on historical data enables the manager to ask the right questions.
Note: Sonar is no way competing with any of the above Static analysis tools rather it complements and works very (really very) close with these tools. In fact it seizes to work if these static analysis tools (Checkstyle, PMD and Findbug) does not exists. Further we can integrate Fortify with Sonar using this plugin