Continuous Inspection in a full stack project with SonarQube
I want to share with you Sparkbit’s approach to software quality assurance and our first experiences with the SonarQube tool.
I am an enthusiast of software measurement and code quality. I will introduce you to one of our projects and describe, why we think we will benefit from using Continuous Inspection in our daily work. Then I will motivate why we decided to choose SonarQube. The article will also cover the detailed technical setup of our SonarQube’s deployment and our choice of plugins and source code metrics. And lastly, I will share our opinion about the tool after the first week of use in the project.
I was happy when our client recently said they want to track metrics for the source code that we deliver, and I was assigned with the task of setting up a tool for that. They needed a proof that the code was reliable and maintainable and that we can keep its quality on the same high level throughout the project.
We’ve already had a CI/CD setup in our project. As part of our software delivery pipeline we do code review, run tests and do static analysis. We use Jenkins and Gerrit for this purpose. We haven’t however integrated any tool for tracking code metrics just yet.
Tools for Continuous Inspection
I also knew SonarQube from my previous research on Continuous Inspection tools. It is open source (LGPL v3 license) and it is backed by the SonarSource company, so it can be used in a range of editions starting from the free Community Edition up to the Ultimate Edition with full support from SonarSource.
Programming Language Support
It is very common to set it up for Java projects. This time, however, we wanted to analyze a full stack project with a big part written in Typescript using the Angular2 framework.
Then I found the SonarTsPlugin plugin on Github. The author says that the plugin is pre-alpha and tested only on Windows, but this was the only thing available, so I decided to give it a try.
Actually, the setup was painless. It sufficed to install Node.js and TsLint, follow the setup steps listed on the plugin website and the plugin started to work right away on our Ubuntu setup.
Hardware and Software Setup
Talking about the setup – for start we used a t2.medium machine from Amazon AWS cloud which has 4GB of RAM. I checked that SonarQube needs a few GB of memory. The Requirements page says that “The SonarQube server requires at least 2GB of RAM to run efficiently and 1GB of free RAM for the OS”. It also uses an SQL database and the Elasticsearch engine. My calculation, therefore, was that I would give 2GB for SonarQube, 1GB for the OS and 1GB for the database and Elasticsearch for a start. For now, this is enough to support daily work of a 10 person project team. If we ever need to grow, we can easily upgrade the machine to t2.large with 8BG of RAM.
Our detailed technical setup is that we have a PostgreSQL database running as service and the SonarQube instance running in a supervisor process on an Ubuntu machine. Disk space should not be an issue. I was quite surprised to read on the above-mentioned Requirements page that the “Nemo the public instance of SonarQube, has more than 15 million lines of code under analysis with 4 years of history. Nemo is currently running on an Amazon EC2 c3.large instance, using about 10 Gb of drive space”. Therefore, the default 80GB available by default with the AWS instance should be more than enough for the SonarQube data and the OS.
By the way – there is also one other public instance of SonarQube running with the SonarTsPlugin available here. It scans big popular TypeScript frameworks, including the Angular Framework, Microsoft Visual Studio Code and the Microsoft TypeScript Compiler.
Configuring the SonarQube Pack
Having the SonarQube up and running, I moved to the Code analysis part. I configured the Git plugin to access our repo and a Jenkins job on our CI server to trigger the Sonar analysis once a day. It was also interesting to find out that SonarSource offers free and open source SonarLint IDE plugins available for Eclipse, IntelliJ and Visual Studio.
The Technical Debt ratio calculation method is described on the Technical Debt page. Let me just say that this metric means the ratio between the actual technical debt and the effort it would take to rewrite the whole source code from scratch.
The SQALE (Software Quality Assessment based on Lifecycle Expectations) rating is based on the so-called “Technical Debt Pyramid”. On the Technical Debt page, it is described in full detail. In our case it looked like this:
Less than 10 man-days to fix all technical debt – not too bad, isn’t it?
Expectations and Results
Actually, the SonarQube analysis revealed some more interesting things, we haven’t known about our project or have simply forgotten in the course of development. One finding was that a currently inactive sub-project of the front end part contained a long forgotten copy of the backend! Sonar pointed it out immediately because on one hand it contained a lot of duplicates (obviously! because of the code copy-paste) and lots of code smells (because it has been inactive for quite a while). Nice thing to know!
Another finding was that one of our active front end projects actually had TSLint rules violations. I was surprised. How could this have happened, if TSLint was part of our every build? The answer was quite simple. There was a bug in our gulp build files. Here the strength of Continuous Inspection shows up. It is always good to have some tool look at the soundness of your build.
I remember a story from one of my previous projects, where at the very end of the project I learned that the script executing all tests had a bug in it, that caused the final test pass/fail condition always to evaluate as true. This was pretty scary because it meant that any potential test fails were actually left undetected. Luckily not so many of them actually failed unnoticed, but anyway we faced some moments of fear when we found out. So here in our current project, the one direct action item was to fix the TSLint rules in this subproject and fix the build script.
The copy-pasted backend code was actually excluded from the project and after that, our Technical Debt ratio dropped to 0.7%.
Project size also dropped to about 19 KLOC. Here are our detailed statistics:
A number of issues are a little more than 600 and we have 4% duplications.
This is the breakdown of issues by categories:
These 5 blockers are relatively easy to fix, so a few hours of work should save us from the scariest bugs.
Here is a look at these issues from another perspective:
Note that after excluding the dead backend part from the project, the technical debt dropped by 2 days.
SonarQube also has nice bubble charts that allow tracking the most troublesome files by comparing the number of issues (Y axis) with the file size in LOC (X axis). Each bubble on the chart represents a particular file in the project and its diameter is proportional to the number of issues in this file.
I’ve also added the history view to our project’s dashboard to track how metrics’ values change over time.
This way it is easy to notice when some duplications suddenly appear or disappear from the project. There is only one slight flaw in this diagram. When both LOC and complexity are presented, the low complexity values (6.5 compared to LOC of >20.000) are invisible.
Summing up, we’ve been using SonarQube in our project for a week now. Installation was very easy and painless. Already on the first day, SonarQube pointed out to us long forgotten, smelly areas in our repo. And it found 5 new critical issues, that our static analysis left unnoticed. It is definitely worth to have such a Continuous Inspection tool in the development pipeline.
What’s still in front of us is to set up tracking tests results and code coverage. We also want to look for new plugins that might be useful for us.
What are your experiences with Continuous Inspection? Do you use SonarQube or maybe some other tools? Do you know any good plugins suitable for full stack projects? We’d love to hear your opinions!