At the beginning of the summer, we announced the long-awaited new “Long Term Support” version, SonarQube 5.6. It comes packed with great features to highlight and help developers manage the leak, and to ensure the security and scalability of large instances.

Now we’re concentrating on the main themes for the 6.x series, and based on the discussions we have had during our City Tour 2016, we’re sure that you’ll be as excited by these new features as you were with the ones in 5.6 LTS.

Better leak management

Support of file move and renaming

SonarQube 5.6 LTS provides all the built-in features you need to monitor and fix the leak on your source code: a project home page that highlights activity on code that was added or modified recently, and a quality gate that turns red whenever bugs or vulnerabilities make their way into new code.

Unfortunately, SonarQube 5.6 doesn’t understand moving or renaming files. That means that if an old file is moved, all its existing issues are closed (including the ones marked False Positive or Won’t Fix), and new ones are (re)opened on the file at its new location. An ugly side effect is that old issues end up in the leak period even though the file wasn’t edited. The end result is noise for development teams who refactor frequently.

This limitation is fixed in SonarQube 6.0, and development teams at SonarSource have been enjoying it for a couple of months already.

Better understanding of bugs and vulnerabilities

Over the past 2 years, SonarSource’s analyzers have reached maturity levels that not only allow them to detect “simple” maintenance issues, but also more tricky issues that can be found only by exploring the code in depth using “symbolic execution” to explore multiple execution paths through the code. That’s why in the 5.x series, Bugs and Vulnerabilities debuted as part of the new SonarQube Quality Model. As you can imagine, it can be very complex to detect a bug when lots of different execution paths have to be explored. As a consequence, it’s easy to guess that it would be hard for a developer to understand why SonarQube is reporting this or that bug without more help. A glance at “SonarAnalyzer for Java: Tricky Bugs are Running Scared” shows that we must print arrows and explanations on the screenshots to help users understand how we discovered a bug.

The next LTS of SonarQube will provide this information out of the box in the web application. Not only will developers see where each bug is, but they’ll be able to display the execution paths (with explanations) that lead to it. This will be a nice improvement to help you fix the leak more easily!

Project Activity Stream

You’re already applying the right process to fix the leak, but sometimes it is hard to know exactly what causes the tiny drops that end up being the leak. The next LTS will keep track of the low-level activities in your project to help you find the source of your leak. For instance, are you facing unexpected new issues in the leak period? You will be able to see that they are due to the activation of a new rule in your quality profile. You want to find which exact commit(s) were not sufficiently tested and caused the quality gate to turn red because of insufficient coverage? You will see commit hashes to more easily link the problem with what happened in the source code repository.

Branching as a first class citizen

While SonarQube provides a feature to handle short-living (feature) branches through its pull request analysis plugin, it currently does very little when it comes to long-living (maintenance) branches, even though we all know that maintenance is a huge part of software development. Unfortunately, SonarQube’s current branch support is minimal at best. The sonar.branch analysis parameter allows you to analyze a branch alongside the trunk version of the code, but under the hood SonarQube treats the branch as a separate, completely unrelated project: configuration isn’t shared, metrics are artificially doubled (for instance the number of lines of code), issues are duplicated in each copy of the code with no link between them, it’s impossible to know at what point of time the maintenance branches diverged from the main one, … etc. In the end, you end up managing the branch as a totally different project, even though it is really the same application.

The next LTS will address all those issues, making it simple to create maintenance branches on existing projects to track activity on the branches and make sure that even in branches, there’s no leak on the new code.

See what’s important to you!

User-needs oriented spaces

In the early days, SonarQube offered the possibility to inject and display any kind of information, mostly thanks to customizable dashboards and widgets. This led to widespread adoption, but at the cost of SonarQube being seen as a multi-purpose aggregation and reporting tool: one plugin would add information from a bug tracking system, another one would add documentation information, … The consequence was that the global and project dashboards became a crazy quilt of both useless and useful information, with everything mixed in together in a big mess.

In the 5.x series, project dashboards were replaced by hardcoded pages dedicated to fit the use cases that SonarQube is meant for: seeing the overall quality of a project on its home page, quickly identifying whether the leak is fixed and the reasons why it might not be, and digging into the details to know more about what’s going wrong. Following the same logic, next LTS of SonarQube will get rid of global dashboards and widgets to provide pages designed to answer the needs of developers, technical leaders, project managers and executives – all this out of the box without having to wonder what to configure.

Powerful project exploration with tags

When focusing on a given project, SonarQube offers everything you need to both get the big picture and dig into the details. When it comes to exploring the whole set of projects available on a SonarQube instance, the only entry point is the ageing “Measures” page. This page currently goes into to much detail (allowing you to query for files, for instance), with difficult-to-use filtering criteria.

The next LTS will replace this page with a brand-new “Projects” page to query projects using advanced filtering similar to what’s on the Issues page. Ultimately, it will support tags on projects. It should help answer questions like: what’s the distribution of “strategic” projects regarding security and reliability ratings? how do “offshore” projects perform in terms of maintainability?

Always up-to-date portfolios

The Governance product allows you to manage application portfolios, usually by mapping the organisational structure of a company. The executive-oriented high level indicators produced by Governance are currently updated once in a while, when a refresh is triggered by some external system (usually a CI job), independent of project analyses. The consequence is that, depending on the frequency of this externally-triggered refresh task, those high-level indicators are imprecisely synchronized with the current status of the relevant projects.

The version of Governance compatible with the next LTS will get rid of the need to trigger this refresh, and update portfolio indicators as soon as one of the underlying projects has been updated. This way, there is no need to set up an external process to trigger portfolio calculation, and no wondering if what you are seeing in SonarQube is up to date or not.

Excellent support of huge instances

Horizontal scalability

One of the targets of the 5.x series was making sure SonarQube would scale vertically to house more projects on a single instance if given more space, more CPU, and more RAM. This was achieved thanks to the architectural changes which led to removing the DB connection from the Scanner side, and to adding Elasticsearch in front of the database. But vertical scalability necessarily has limits – namely those of the underlying hardware.

The next LTS will allow you to deploy SonarQube as a cluster of SonarQube nodes. You’ll be able to configure each node for one or more components of SonarQube (web server, compute engine and Elasticsearch node), based on your load. The first instance to benefit from this capability will be SonarQube.com, the SonarQube-based service operated by SonarSource.

Organizations

When talking about large instances, one topic that often comes up is how to efficiently and correctly handle the permissions for large numbers of users and projects. Let’s take the example of an IT department serving several independent business units: the business units might not share the same quality profiles (because they’re working with different technologies), and each one probably wants to define its own user groups, or make specific configurations to suit their needs. There’s currently no good way to manage this scenario, but in the next LTS, organizations will create a way to define umbrellas that isolate sets of users and projects to achieve these goals. As with the ability to set up a cluster, SonarQube.com will be the first instance to benefit from this, so that users can group their projects together and customize settings or quality profiles for them.

Webhooks for Devops

Not related to big instances only, but still in the hands of DevOps teams who operate complex ALM setups, webhooks will increase your ability to integrate SonarQube with existing infrastructure. For instance, freshly built binaries shouldn’t be deployed to production if they don’t pass the quality gate, right? With webhooks, you’ll be able to have SonarQube notify the build system of the projects’ quality gate status so it can cancel or continue the delivery pipeline as appropriate.

Target is mid-2017!

That’s all folks! The estimated time of arrival for the next SonarQube 6.x LTS is mid-2017. Expect other small but useful features to make their way along those big themes!