We’re excited to announce that we’ve finally determined where and when Selenium Conf will be happening this Fall.
Our initial goal was to bring the event to a new country, but for a number of reasons that proved more challenging than we’d hoped. But in 2012 we had the 2nd annual Selenium Conf in London, and we’re pleased to be bringing it back there this year!
The conference will be held at The Mermaid in downtown London on November 14-16:
- The 14th will be all-day pre-conference workshops
- The 15th-16th will be the conference
Go here to sign up for the email list for conference updates (e.g., when tickets go on sale) as well as submit a talk. Call for speakers are open from now until July 29th.
SonarAnalyzers are fundamental pillars of our ecosystem. The language analyzers play a central role, but the value they bring isn’t always obvious. The aim of this post is to highlight the ins and outs of SonarAnalyzers.
The goal of the SonarAnalyzers (packaged either as SonarQube plugins or in SonarLint) is to raise issues on problems detected in source code written in a given programming language. The detection of issues relies on the static analysis of source code and the analyzer’s rule implementations. Each programming language requires a specific SonarAnalyzer implementation.The analyzer
The SonarAnalyzer’s static analysis engine is at the core of source code interpretation. The scope of the analysis engine is quite large. It goes from basic syntax parsing to the advanced determination of the potential states of a piece of code. At minimum, it provides the bare features required for the analysis: basic recognition of the language’s syntax. The better the analyzer is, the more advanced it’s analysis can be, and the trickier the bugs it can find.
Driven by the will to perform more and more advanced analyses, the analyzers are continuously improved. New ambitions in terms of validation require constant efforts in the development of the SonarAnalyzers. In addition, to be able to handle updates to each programming language, regular updates are required in the analyzers to keep up with each language’s evolution.The rules
The genesis of a rule starts with the writing of its specification. The specification of each rule is an important step. The description should be clear and unequivocal in order to be explicit about what issue is being detected. Not only must the description of the rule be clear and accurate, but code snippets must also be supplied to demonstrate both the bad practice and it’s fix. The specification is available from each issue raised by the rule to help users understand why the issue was raised.
Rules also have tags. The issues raised by a rule inherit the rule’s tags, so that both rules and issues are more searchable in SonarQube.
Once the specification of a rule is complete, next comes the implementation. Based on the capabilities offered by the analyzer, rule implementations detect increasingly tricky patterns of maintainability issues, bugs, and security vulnerabilities.Continuous Improvement
The analysis of other languages can be enabled by the installation of additional SonarAnalyzer plugins.
SonarQube community officially supports 24 language analyzers. Currently about 3500 rules are implemented across all SonarAnalyzers.
More than half of SonarSource developers work on SonarAnalyzers. Thanks to the efforts of our SonarAnalyzer developers, there are new SonarAnalyzer versions nearly every week.
In 2015, we delivered a total of 61 new SonarAnalyser releases, and so far this year, another 30 versions have been released.What it means for you
You can easily benefit from the regular delivery of SonarAnalyzers. At each release, analyzer enhancements and new rules are provided. But, you don’t need to upgrade SonarQube to upgrade your analysis; as a rule, new releases of each analyzers are compatible with the latest LTS.
When you update a SonarAnalyzer, the static analysis engine is replaced and new rules are made available. But at this step, you’re not yet benefiting from those new rules. During the update of your SonarAnalyzer, the quality profile remains unchanged. The rules executed during the analysis are the same ones you previously configured in your quality profile.
It means that if you want to benefit from new rules you must update your quality profile to add them.
With the release of SonarQube version 5.6, the entire Sonar ecosystem will drop support for Java 7. This means you won’t be able to run new versions of the SonarQube server, execute an analysis, or use SonarLint with a JVM < 8.
Why? Well, its been over two years since Java 8′s initial release, and a year since Oracle stopped supporting Java 7, so we figured it was time for us to stop to. Doing so allows us to simplify our development processes and begin using the spiffy new features in Java 8. Plus, performance is up to 20% better with Java 8!
Of course, we’ll still support running older versions of ecosystem products, e.g. SonarQube 4.5, with Java 7, and you’ll still be able to compile your project with a lower version of Java. You’ll just have to bump up the JVM version to run the analysis.
The wait is over! The new SonarQube Long Term Support (LTS) version is out, and it’s packed with new features to help you better manage your technical debt and operational security. It has been over a year and a half since the last Long Term Support (LTS) version was announced – a very busy year and a half. In that time, we’ve pursued three main themes:
- Fixing the Leak
- Adding More for Developers
- Increasing Scalability and Security
The Water Leak concept says you should fix new issues before bothering with old ones. After all, an issue in two-year-old code has been tested by time. Its the one you added yesterday that should be fixed immediately – while the code is still fresh in your mind.
To that end, we’ve added a number of features to keep you focused on the leak. The first is a new, fixed project home page which puts the leak front and center (okay, front and right) by highlighting the metrics on new code:
And just to make sure it doesn’t slip from view, we’ve updated the default quality gate to focus on new code as well:
Of course, it’s best of all if new problems never hit the code base. In an effort to shorten the cycle we also added the ability to analyze pull requests. Now you no longer need to wait for your code to hit the SonarQube server to see what you need to fix. Instead, you can see new issues as comments on your GitHub pull request (PR):
This is enabled as a GitHub status check, so analysis is automatic with each new push to the PR and you get a tidy summary in the check list:
As a company of developers, and our own first users and harshest critics, we’re always focused on making the platform more usable for developers. It should come as no surprise then, that there’s a lot for developers in this version!
I’ll start with the SonarQube Quality Model, which is an easy to understand, actionable model that takes the best from SQALE and adds what was missing. It draws bugs and security vulnerabilities out of the mass of maintainability issues to clearly highlight project risk, while retaining the calculation of technical debt.
Click through on any of these issue counts, and you land at the new issues page, which is available at both global and project levels. It features an easy-to-use search, totals by either count or technical debt, and super-easy keyboard (or mouse!) navigation:
On that issues page, you may notice the next developer-centric feature: precise issue location. Now we can highlight exactly, and only the portion(s) of a line relevant to the issue:
Last but not least on the topic of Issue improvements is False Positive’s long-awaited sister: Won’t Fix:
We’ve also reworked the presentation of Metric details. The old drilldowns have been replaced by a new project Measures space, which offers a general overview:
A domain view:
A treemap, a list of files, a component tree, and of course a file listing
Even though SonarSource is a developer-centric company, we didn’t forget devops. In fact, this new LTS makes great strides in that area.
The most significant change is that analyzers no longer talk to the database. This means you don’t have to hand out your DB credentials to every Joe who wants to run an analysis. Instead, scanners talk only to the web server, and the server takes it from there.
“But wait,” you’re thinking, “you still have to pass around the user credentials to submit an analysis.”
No you don’t. We’ve added the ability to generate user tokens, so you can run an analysis without exposing your password (or user name!).Also Worth Noting
While it shouldn’t be major news, it’s also worth noting that the new LTS drops support for Java 7. It’s Java 8+ from here on out. Among other things, the change should make your SonarQube server even faster than before!That’s all, Folks!
If you’ve already worked with the 5.x series, few of these things will come as a surprise. If you’re still on the previous LTS, you should fasten your seat belt. It’s gonna blow your socks off!
In SonarQube 5.5 we adopted an evolved quality model, the SonarQube Quality Model, that takes the best from SQALE and adds what was missing. In doing so, we’ve highlighted project risks while retaining technical debt.
Why? Well, SQALE is good as far as it goes, but it’s primarily about maintainability, with no concept of risk. For instance, if a new, blocker security issue cropped up in your application tomorrow, under a strict adherence to the SQALE methodology you’d have to ignore it until you fixed all the Testability, Reliability, Changeability, &etc issues. When in reality, new issues (i.e. leak period issues) of any type are more important than time-tested ones, and new bugs and security vulnerabilities are the most important of all.
Further, SQALE is primarily about maintainability, but the SQALE quality model also encompasses bugs and vulnerabilities. So those important issues get lost in the crowd. The result is that a project can have blocker-level bugs, but still get an A SQALE rating. For us, that was kinda like seeing a green light at the intersection while cross-traffic is still flowing. Yes, it’s recoverable if you’re paying attention, but still dangerous.
So for the SonarQube Quality Model, we took a step back to re-evaluate what’s important. For us it was these things:
- The quality model should be dead simple to use
- Bugs and security vulnerabilities shouldn’t be lost in the crowd of maintainability issues
- The presence of serious bugs or vulnerabilities in a project should raise a red flag
- Maintainability issues are still important and shouldn’t be ignored
- The calculation of remediation cost (the use of the SQALE analysis model) is still important and should still be done
To meet those criteria, we started by pulling Reliability and Security issues (bugs and vulnerabilities) out into their own categories. They’ll never be lost in the crowd again. Then we consolidated what was left into Maintainability issues, a.k.a. code smells. Now there are three simple categories, and prioritization is easy.
We gave bugs and vulnerabilities their own risk-based ratings, so the presence of a serious Security or Reliability issue in a project will raise that red flag we wanted. Then we renamed the SQALE rating to the Maintainability rating. It’s calculated based on the SQALE analysis model (technical debt) the same way it always was, except that it no longer includes the remediation time for bugs and vulnerabilities:
To go help enforce the new quality model, we updated the default Quality Gate:
- 0 New Bugs
- 0 New Vulnerabilities
- New Code Maintainability rating = A
- Coverage on New Code >= 80%
The end result is an understandable, actionable quality model you can master out of the box; quality model 2.0, if you will. Because managing code quality should be fun and simple.
SonarLint is a pretty recent product that we released for the first time a few months ago for Eclipse, IntelliJ and Visual Studio. We have recently released the version 2.0 which brings the ability to connect SonarLint with a SonarQube server and was greatly expected by the community. I think the addition of this new feature is a good chance to recap SonarLint features. But before I do this, let me remind you of the SonarLint’s mission: to help developers spot as many coding issues as possible in their IDE, while they code. It has to be instant, integrated to the IDE, and valuable.
Since SonarLint 1.0, you can install the product from the market place for all 3 IDEs we currently support: Eclipse Marketplace, Jetbrains Plugin Repository or Visual Studio Gallery. Et voilà… You can continue your coding as usual and you will start seeing SonarLint issues reported as you type. If you open a file, it will get decorated immediately with issues.
You also benefit from a nice panel containing a list of issues that have been detected. Each issue comes with a short message and if that is not enough you can open a more detailed description of the problem, with code snippets and references to well known coding standards.
As I am sure you guessed already, all of this does not require any configuration. And this is actually the reason why version 2.0 was so expected: people who have defined their quality profile in SonarQube want to be able to use the same profile in SonarLint. This is the main feature provided by SonarLint 2.0.
In order to have SonarLint use the same quality profile as SonarQube you have to bind your project in your IDE to the remote project in SonarQube. This is done in two steps:
- Configure a connection to your SonarQube server (URL + credentials)
- Bind your project with the remote one
Et voilà… again… SonarLint will fetch configuration from the SonarQube server and use it when inspecting code.
That’s it for today!