Since we love touring and meeting our community of users, we’re setting out on the road once again, this time to more cities than ever! Over the next 6 months you’ll be able to see us and ask any questions you have, in more than 10 cities in Europe and the US.
This year, we are very excited to return to the City Tour to share with you all the news around the SonarQube platform, and show you our latest product: SonarLint, which allows developers to track quality of their code in real time as they type it. Very powerful!
Here is what will be covered at each stop of the tour:
- The Leak Approach: a new paradigm to manage Code Quality
- SonarQube 5.x series in demo
- SonarQube integration to Microsoft ALM
- SonarLint, the missing piece of the puzzle
- Customer feedback
- Sonar Analyzers and well-established standards
- Roadmap for the platform
- Roadmap for Sonar Analyzers
It will also be a great opportunity to meet other SonarQube users to share tips and tricks and discuss your experiences with the platform.
Is there something you would like to know or ask us but haven’t had the opportunity to do so? Now’s your chance! Sign up for the free event in your preferred city, and we’ll see you soon!
Registrations are open on our website, so pick the city you want, fill the form and you’ll be all set.
Join the conversation by using #SSCT2016 in all your tweets about the events.
See you soon !
For the past year, the SonarSource team behind the SonarAnalyzer for Java has invested most of its time in developing a Symbolic Execution engine in order to find the kind of tricky bugs that are almost uncatchable by developers unaided.
The SonarAnalyzer for Java’s new symbolic execution engine allows it to statically trace all the execution paths in a piece of code. We’ll probably do a blog post in the near future to explain all the related concepts: Program Point, Program State, Symbolic Value, Control Flow Graph, Stack of Symbolic Values, Constraints on Symbolic Values, … but for the time being let’s just see the engine in action.
Example 1 is a null pointer dereference in the Apache Tika project. The nullability of an object is guessed here from a test done in the code.
Example 2 is also an NPE in the Apache Tika project. This time the nullability is due to a badly handled exception.
Example 3 is a useless condition in the Spark project.
Example 4 returns to Apache Tika with a suspect unreachable branch.
Based on those few examples I guess it’s pretty easy to understand how valuable it can be to quickly get this information early in the development lifecycle. So how can you benefit from the SonarAnalyzer for Java? Either by getting on-the-fly feedback directly in your favorite Java editor with SonarLint for Eclipse or SonarLint for IntelliJ, Or by integrating SonarQube analysis into your build process to continuously feed the SonarQube server.
Tricky bugs are running scared. The hunt is on!
So there you are: you’ve finally decided to install the SonarQube platform and run a couple of analyses on your projects, but it unveiled so many issues that your team doesn’t know where to start. Don’t be tempted to start fixing issues here and there! It could be an endless effort, and you would quickly be depressed by the amount of work that remains. Instead, the first thing you should do is make sure your development team fixes the leak. Apply this principle from the very beginning, and it will ensure that your code is progressively cleaned up as you update and refactor over time. This new paradigm is so efficient at managing code quality that it just makes the traditional “remediation plan” approach obsolete. Actually, so obsolete that related features will disappear in SonarQube 5.5: action plans and the ability to link an issue to a third party task management system.
“Why the heck are you dropping useful features? Again!?…”
Well, we’ve tried to dogfood and really use those features at SonarSource ever since we introduced them – but never managed to. Maybe the most obvious reason we never used them is that far before conceptualizing the “Leak” paradigm, we were already fixing the leak thanks to appropriate Quality Gates set on every one of our projects. And while doing so, nobody was feeling the need to rely on action plans or JIRA to manage his/her issues.
There are actually other reasons why those features never got used. First, action plans live only in the SonarQube server, so they don’t appear in your favorite task management system. Because of that, chances are that you will eventually miss the related dead-lines. This is why you might be tempted to “link issues” to your task management system. But this “Link to” feature isn’t any better. Let’s say you’re using JIRA in your company. When you link an issue to JIRA, the SonarQube integration automatically creates a ticket for that issue. So if you want to keep track of 100 issues, you’ll end up with 100 JIRA tickets that aren’t really actionable (you just have a link back to SonarQube to identify every single issue) polluting your backlog. What’s even worse is that when an issue gets fixed in the code, it will be closed during the next SonarQube analysis, but the corresponding ticket in JIRA will remain open! Anyway, issues in the SonarQube server and tickets in JIRA just don’t have the same granularity.
“Still, there are cases when I really want to create a remediation plan. How can I do that?”
As discussed previously, you should really avoid defining a remediation plan, and take the opportunity instead to spend the energy on “fixing the leak” instead. Still, occasionally, you might be forced to do so. The main case we can think of is when you absolutely want to fix critical bugs or vulnerabilities found on legacy code that might really affect your business if they pop up in production. In that scenario, indeed you might want to create a dedicated remediation plan so that your development team gets rid of this operational risk.
The good thing is that SonarQube already has everything you need to clearly identify all those issues and plan a task to make sure they got fixed – whatever task management system you’re using:
- In the SonarQube UI:
- Start tagging issues you want to fix with a dedicated and specific tag, like “must-fix-for-v5.2″
- Create a public “issue filter” that displays only issues tagged with ”must-fix-for-v5.2″
- In your task management system:
- Create a ticket in which you reference the URL of the issue filter
- Set a due date or a version
- You’re done! You have a remediation plan that you can manage like any other task and your team won’t forget to address those issues.
“I don’t need anything more then?”
Well, no. Defining remediation plans this way gives the best of both worlds: identifying issues to fix in the SonarQube UI, and planning the correspond effort in your own beloved task management system.
And once again, remember that if your team fixes the leak, chances are you will not need to create a remediation plan any longer. So yes, even if I’m the one who initially developed Action Plans and the “Link to” features a long time ago, I think it’s really time to say bye bye…
The team is proud to announce the release of 5.4, a more usable and informative version than ever before:
- New “My Account” space to collect all your data in once place
- “Execute Analysis” permission can now be granted at the project level
- OAuth2 support
- New “Code” page to list and search for the files in your project
- Server restart from the UI
- Cross-module duplication is back!
This version of the SonarQube server offers an almost complete overhaul of the “My Account” space to offer developers quicker access to their data:
Previously, an administrator had to manage these for you. Now the power is in your hands!“Execute Analysis” permission can now be granted at project level
Once you’ve installed the appropriate plugin, you’ll find its configurations under Administration > General > Security > [Provider].New “Code” page to list and search for the files in your project
The venerable Components page has been replaced with a new “Code” space, which offers a more natural code browsing experience. Additionally, it offers a search that’s constrained to your project, versus the global search in the upper right:
Since not everyone who administers a SonarQube instance has direct access to the filesystem, we’ve added the ability to restart the platform from the UI. You’ll find it in the Update Center when there are installs or updates pending:
There’s not a lot to show here, but we’d be remiss in not mentioning the return of cross-module duplication detection. You may remember it was dropped in 5.2 because that version’s extensive changes meant a complete re-write of cross-project and cross-module detection was needed. 5.3 brought back cross-project detection and 5.4 finishes the restoration of the feature.That’s All, Folks!