A perfect article for the enthusiasts of software measurement and code quality. Contains broadened introduction and description of first experiences with the SonarQube tool. Explains in details configuration process, code evaluation and benefits from using Continuous Inspection in developers' daily work. Additionally, shows how to analyze a full stack project with a big part written in Typescript using the Angular2 framework.

1. Continuous Inspection in a full stack project
with SonarQube
Pawe?Kozio?
May2016
I am an enthusiast of softwaremeasurement
and codequality. I will introduceyou to oneof our
projectsand describe, why wethink wewill benefit
from usingContinuousInspection in our daily work.
Then I will motivatewhy wedecided to choose
SonarQube. Thearticlewill also cover thedetailed
technical setup of our SonarQube?sdeployment and
our choiceof pluginsand sourcecodemetrics. And
lastly, I will shareour opinion about thetool after the
first week of usein theproject.
I washappy when our client recently said they want
to track metricsfor thesourcecodethat wedeliver,
and I wasassigned with thetask of settingup atool
for that. They needed aproof that thecodewas
reliableand maintainableand that wecan keep its
quality on thesamehigh level throughout the
project.
We?vealready had aCI/CD setup in our project. As
part of our softwaredelivery pipelinewedo code
review, run testsand do staticanalysis. Weuse
Jenkinsand Gerrit for thispurpose. Wehaven?t
however integrated any tool for trackingcode
metricsjust yet.
Toolsfor ContiuousInspection
Thereareafew such toolsavailable, however, most
of them areold and no longer maintained. Examples
aretheQALab and theXRadar, which werelast
updated morethan 7yearsago.
I also knew SonarQubefrom my previousresearch
on ContinuousInspection tools. It isopen source
(LGPL v3license) and it isbacked by the
SonarSourcecompany, so it can beused in arangeof
editionsstartingfrom thefreeCommunity Edition
up to theUltimateEdition with full support from
SonarSource.
ProgrammingLanguagesSupport
SonarQubehassupport for morethan 20
programminglanguagesincludingJava, C#, C/C++
and Javascript. It analyzesthecodeand evaluatesits
maintainability takinginto consideration tests,
documentation, duplications, potential bugs,
complexity and other aspects.
It isvery common to set it up for Javaprojects. This
time, however, wewanted to analyzeafull stack
project with abigpart written in Typescript using
theAngular2framework.
I want to share with you Sparkbit?s approach to software quality assurance and our
first experiences with the SonarQube tool.

2. At first, I wasworried, if it would bepossible. I saw
that SonarQubehasbuilt in Javascript support,
however, I knew that analyzingTypescript codeas
Javascript would not bepossible. Typescript isa
superset of JS, so JScodeisvalid TScodebut not the
other way around.
Then I found theSonarTsPlugin plugin on Github.
Theauthor saysthat theplugin ispre-alphaand
tested only on Windows, but thiswastheonly thing
available, so I decided to giveit atry.
Actually, thesetup waspainless. It sufficed to install
Node.jsand TsLint, follow thesetup stepslisted on
theplugin websiteand theplugin started to work
right away on our Ubuntu setup.
Hardwareand softwaresetup
Talkingabout thesetup - for start weused a
t2.medium machinefrom Amazon AWScloud which
has4GBof RAM.
I checked that SonarQubeneedsafew GBof
memory. TheRequirementspagesaysthat ?The
SonarQubeserver requiresat least 2GBof RAM to
run efficiently and 1GBof freeRAM for theOS?.
It also usesan SQL databaseand theElasticsearch
engine. My calculation, therefore, wasthat I would
give2GBfor SonarQube, 1GBfor theOSand 1GB
for thedatabaseand Elasticsearch for astart. For
now, thisisenough to support daily work of a10
person project team. If weever need to grow, wecan
easily upgradethemachineto t2.largewith 8BGof
RAM.
Our detailed technical setup isthat wehavea
PostgreSQL databaserunningasserviceand the
SonarQubeinstancerunningin asupervisor process
on an Ubuntu machine. Disk spaceshould not bean
issue. I wasquitesurprised to read on the
above-mentioned Requirementspagethat the?Nemo
thepublicinstanceof SonarQube, hasmorethan 15
million linesof codeunder analysiswith 4yearsof
history. Nemo iscurrently runningon an Amazon
EC2c3.largeinstance, usingabout 10Gb of drive
space?. Therefore, thedefault 80GBavailableby
default with theAWSinstanceshould bemorethan
enough for theSonarQubedataand theOS.
By theway - thereisalso oneother publicinstanceof
SonarQuberunningwith theSonarTsPlugin
availablehere. It scansbigpopular TypeScript
frameworks, includingtheAngular Framework,
Microsoft Visual Studio Codeand theMicrosoft
TypeScript Compiler.
HavingtheSonarQubeup and running, I moved to
theCodeanalysispart. I configured theGit plugin to
accessour repo and aJenkinsjob on our CI server to
trigger theSonar analysisonceaday. It wasalso
interestingto find out that SonarSourceoffersfree
and open sourceSonarLint IDEpluginsavailablefor
Eclipse, IntelliJand Visual Studio.
CodeEvaluation
Thefirst analysisrevealed that our project hasabout
25KLOCof Typescript, Javascript, Javaand XML
code. SonarQubehasfound morethan 800issuesin
our code, most of them beingMinor or Major ones
(about 300issuesin each category).
Thiswasquitesurprisingbecausewerun Findbugs
and TSLint on our codein theCI process, so we
expected amuch better result. Better newswasthat
thewholeTechnical Debt ratio waslessthan 1%and
wegot theSQALE?A?rating, beingthetop of the
scale. Wow! That wasapretty impressiveresult to
get on thefirst run.
TheTechnical Debt ratio calculation method is
described on theTechnical Debt page. Let mejust say
that thismetricmeanstheratio between theactual
technical debt and theeffort it would taketo rewrite
thewholesourcecodefrom scratch.
TheSQALE(SoftwareQuality Assessment based on
LifecycleExpectations) ratingisbased on the
so-called ?Technical Debt Pyramid?. On the
Technical Debt page, it isdescribed in full detail. In
our caseit looked likethis:
Lessthan 10man-daysto fix all technical dept - not too bad, isn't it?

3. Expectationsand Results
Actually, theSonarQubeanalysisrevealed somemore
interestingthings, wehaven?t known about our
project or havesimply forgotten in thecourseof
development. Onefindingwasthat acurrently
inactivesub-project of thefront end part contained a
longforgotten copy of thebackend! Sonar pointed it
out immediately becauseon onehand it contained a
lot of duplicates(obviously! becauseof thecode
copy-paste) and lotsof codesmells(becauseit has
been inactivefor quiteawhile). Nicethingto know!
Another findingwasthat oneof our activefront end
projectsactually had TSLint rulesviolations. I was
surprised. How could thishavehappened, if TSLint
waspart of our every build?Theanswer wasquite
simple. Therewasabugin our gulp build files. Here
thestrength of ContinuousInspection showsup. It is
alwaysgood to havesometool look at thesoundness
of your build.
I remember astory from oneof my previousprojects,
whereat thevery end of theproject I learned that the
script executingall testshad abugin it, that caused
thefinal test pass/fail condition alwaysto evaluateas
true. Thiswaspretty scary becauseit meant that any
potential test failswereactually left undetected.
Luckily not so many of them actually failed
unnoticed, but anyway wefaced somemomentsof
fear when wefound out. So herein our current
project, theonedirect action item wasto fix the
TSLint rulesin thissubproject and fix thebuild script.
Thecopy-pasted backend codewasactually excluded
from theproject and after that, our Technical Debt
ratio dropped to 0.7%.
Project sizealso dropped to about 19KLOC. Hereareour detailed statistics:
A number of issuesarealittlemorethan 600and wehave4%duplications.

4. Thisisthebreakdown of issuesby categories:
These5blockersarerelatively easy to fix, so afew hoursof work should saveus
from thescariest bugs.
Hereisalook at theseissuesfrom another perspective:
Notethat after excludingthedead backend part from theproject, thetechnical
debt dropped by 2days.
I?vealso added thehistory view to our project?sdashboard to track how metrics?valueschangeover time.
Thisway it iseasy to noticewhen someduplicationssuddenly appear or disappear from theproject. Thereis
only oneslight flaw in thisdiagram. When both LOCand complexity arepresented, thelow complexity
values(6.5compared to LOCof >20.000) areinvisible.

5. SonarQubealso hasnicebubblechartsthat allow
trackingthemost troublesomefilesby comparingthe
number of issues(Y axis) with thefilesizein LOC(X
axis). Each bubbleon thechart representsa
particular filein theproject and itsdiameter is
proportional to thenumber of issuesin thisfile.
Conclusion
Summingup, we?vebeen usingSonarQubein our
project for aweek now. Installation wasvery easy
and painless. Already on thefirst day, SonarQube
pointed out to uslongforgotten, smelly areasin our
repo. And it found 5new critical issues, that our
staticanalysisleft unnoticed. It isdefinitely worth to
havesuch aContinuousInspection tool in the
development pipeline.
What?sstill in front of usisto set up trackingtests
resultsand codecoverage. Wealso want to look for
new pluginsthat might beuseful for us.
What areyour experienceswith Continuous
Inspection?Do you useSonarQubeor maybesome
other tools?Do you know any good pluginssuitable
for full stack projects?We?d loveto hear your
opinions!

6. CONTACT
pawelk@sparkbit.pl
www.sparkbit.pl
@_sparkbit_