SonarQube Reviews

Primary use is code standards, or code quality. It's worked out okay. I find it is light on the security side though.

We brought into our CI pipeline to see if we could help our developers fix issues and identify issues sooner.

• Higher code quality. 
• Faster to market.
• Less errors.
  

• The issues it identifies.
• How easily it ties into our continuous integration pipeline.
• It is very good at identifying technical debt.

As far as code quality goes, I like it. It doesn't seem to do well when it comes to vulnerabilities on the security side. It may be that we don't have the right plugins, or we don't have the right add-ons.

It seems to be very stable. I haven't had many issues with it. 

We just upgraded to the 6.7 version, which has been performing well.

We haven't had any issues to date. We haven't had a huge number of projects to date. We're slowly slowing the uptake from some of our internal teams, but it seems to be fairly scalable.

I haven't had to use technical support.

The initial setup was fairly straightforward.

The price point on SonarQube is good.

We are looking into corporate security and a couple different tooling options for doing data code analysis and security scanning.

We have looked into a few options: 

• We are looking at IBM AppScan.
• I am going to be running a small PoC next week with Veracode. I started doing a bit of research on Veracode, and I saw how it ties in compared with SonarQube.

We are looking at using another product to compliment it for security reasons.

Most important criteria when selecting a vendor:

• Usability of the product
• Responsiveness when we have issues.

SonarQube is not valuable because of the information it gives it. We can gather that same information from several other tools as well. It is the way the information is presented that makes it so powerful. It provides a holistic picture of all quality issues in a software project. With SonarQube's web interface, it is easy to drill down to see the individual problems, but also to look at the project from above and get the big picture, with possible larger problem areas.

Individual developers are more concerned about the quality of their work when they see their results in the big picture.

About a year, in different projects, including the current one.

No.

No.

Not used.

We used the same tests, but with every developer running them individually. Now management can also get a picture of the quality assurance.

Very simple.

Price is high and only worth it if your organization has hundreds of developers.

No.

This product has helped us improve the quality of code within the business and ensure all new developers keep to a similar code convention per project. This can basically be tracked back to saving the company money, because improved quality of the code means less technical debt which means it's easier to extend or add functionality to the code base. The quicker the development team can roll out changes, the less developer hours needed to implement the changes, which the company needs to convert into profits.

Most features in the product are very useful, but there are some parts that I personally use more than others.

1. Code Convention: Using the tool to implement some sort of coding convention is really useful and ensures that the code is consistent no matter how many contributors.

A very usual addition to this tool is an IntelliJ plugin called SonarLint, which integrates into your IDE, then allows you to run the convention rules file by file and receive immediate feedback when making changes. This removes the need to push to the server before finding out what issues you need to resolve.

2. Technical Debt: Being able to see how much technical debt there is within the project is useful, especially if your change increases this value. It's a good way to determine whether your change is improving the overall code quality or not.

3. Graphing: The tool has some very useful graphs which give you an overall view of how the code looks and/or changes with time. A graph that I find useful is the bubble chart. It shows three different metrics in a 2D graph. It shows the number of lines of code versus the number of issues in that project. The third dimension is the size of the bubble, which is technical debt in the project. So it's very easy to see which projects need immediate attention, if they are in the top-right quadrant of the graph as a very large circle, i.e., high number of issues, high number of lines of code, and high technical debt. Seeing which project/submodule is in which quadrant of the graph shows where work is needed. You can also drill into the project and see any submodules within that project as well. Very useful.

• Upgrading the version of the server is a bit cumbersome and could be made slightly easier. Allowing admin users to upgrade the software through the front-end would make upgrading easier.
• Another improvement is with false positives. Sometimes the tool can say there is an issue in your code but, really, you have to do things in a certain way due to external dependencies, and I think it's very hard to indicate this is the case. There is a way to mark the code/method with the issue number, but having to add comments/annotations in your code for your static analysis tool feels wrong to me.
• Being able to have different groups or projects within the same server would be nice. Currently, I have a Sonar machine for production code (master branch) and UAT code (UAT branch), so when each branch is built in our continuous integration server it publishes to these two Sonar machines. What would be nice is if I could create subgroups within a single SonarQube server for each environment to remove the need for two separate machines.

It seems a lot more stable in the current versions of the product. I have never had major issues though, so I would say it's pretty stable.

I haven't yet found any scalability issues, although with the upgrade to version 6, they have moved the processing of the stats from outside the server to inside the server. What I have noticed is that the machines running SonarQube are using a lot more resources, as the processing is done server side. This means that I need to increase the resources allocated to the machine. If I was running this in the cloud, it would be easy, as I would create a larger instance for the service. But as I have this running on a physical machine, I am limited to what I can allocate.

I haven't used their technical support.

Yes, I have used individual components which SonarQube uses, such as FindBugs, but having the static analysis run and reported back within a continuous integration server. This gives you back some of the results, but SonarQube is a single, complete solution for static analysis and has added improvements like a great UI and visualisations.

Initial setup was pretty easy. I currently run this in a virtual Linux (Ubuntu) machine using Vagrant and VirtualBox. Installation using apt-get was pretty simple. I then bundled it all up into a new Vagrant box which means I can spin up a new instance of SonarQube whenever and wherever I am (like a custom AMI on AWS), but locally.

I am using the open source version of the product, so no cost. The licence is standard open source licensing, LGPL, so nothing to advise really.

I didn't. I am not sure if there are any other open source static analysis tools as good as this that I have found; Well at least three or four years ago there weren't.

I would advise to get it done sooner rather than later. The sooner you have a better understanding of the state of your code base, the sooner you can make better business decisions based on that information.

Also, even though you may be a sole developer, I think it's still useful to use this tool and have these metrics at your finger tips. It's like version control, even if you are the only developer, I think it should be used for everything you do.

It's enabled us to improve software quality and help us to disseminate best practices.

This product is open source and very convenient.

A better design of the interface and add some new rules.

Only common issues have been experienced.

Only common issues have been experienced.

Customer Service:

I can't rate because there was no customer service.

Technical Support:

The technical documentation is really good and the community is great and active.

Nothing was implemented before this software, only PMD, a light control tool.

The technical documentation online is easy to understand, so the initial setup is straightforward. However, they need to adapt your organization's constraints to the software, which is more difficult.

We did it in-house.

This product is, to my mind, a reference so that if you decide to put in place this software, you will improve the quality control inside your organization. Simple and effective.

SonarQube ensures that we release a good quality of code to our customers. We have incorporated test driven development within the organization. It is also very helpful to bring a DevOps culture within the organisation.

I follow Quality Gate's graduation model within organization, and it is extremely helpful for me to benchmark products.

Well, load balancing is something we expect it to have. Also, sometimes the loading dashboards are a little slow. When we have a thousand products published over it, we expect it to be more efficient in terms of serving requests from the browser.

No.

Yes, a little bit.

Good.

Previously, we used to use regular code review (static analysis, coverage tools) without much into single dashboard. SonarQube helped to put everything together into place supporting almost all languages, or quality profiles.

Simple to setup.

People can try the free licenses and later can seek buying plugins/support, etc. once they started liking it.

Not really.

SonarQube provides easy upgrade mechanisms, and I rarely found any issues.

Use a good VM for hosting, which can serve large requests on the fly with Oracle DB, etc.

It has improved code quality and helped shift quality left. It also paved the way for implementing Continuous Integration/Continuous Delivery.

The customizable dashboard and ability to include results and coverage from unit test and other static analysis code tools.

Ease of use/interface.

I didn't encounter any issues with stability.

No - the tool was implemented in a pilot, and successfully scaled to the enterprise.

Fairly good.

Yes, we used PMD, FindBugs and FxCop. Switched for the reporting and dashboard capabilities.

There was a bit of a learning curve and some customization to get it to work, but nothing too complex.

Get the paid version which allows the customized dashboard and provides technical support.

Do your research to make sure the tool is a good fit for your organization.

Also, give the development teams some time to adapt to the standards - set the thresholds lower to begin with, and then gradually raise it to desired levels, rewarding compliance and good behavior.

Better live process: More automated quality control in the lifecycle of development/testing/deployment/production. This includes the prevention of potential bugs due to ineffective code, as well as keeping a more unified style of solutions. This is thanks to standard solutions offered by the issue tips. It raises code maintainability as well as flexibility, to some extent.

Quality Gate: Automated rules for determining if a project is above or below a quality threshold. This is a concise "red"/"green" style, basic quality-control. This is integrated in the development and deployment process.

Issue Explanations: Documentation with detailed samples. Helps in growing technical knowledge and re-writing logic to conforming solutions.

Deep intelligence and smarter code analysis: There are many cases where a bug or critical issue is reported. However, there is very little chance of rewriting the solution in some other way due to several circumstances. The written solution is actually safe.

It requires advanced heuristics to recognize more complex constructs that could be disregarded as issues.

There is a manual false positive feature for that, so it compensates for it. However, time and time again, some issues become annoying, since they are actually not issues. This can be time-tested though and configured/fine-tuned throughout working with the tool.

There were no stability issues. I can't think of any serious issues.

There were no scalability issues, not as far as the development environments are concerned. I guess if there were tens of repos and maybe hundreds of commits per day, the analysis time would probably suffer. I suppose there is a way to cluster the solution somehow. I'm not sure. I never needed anything like it at the current scale that we have operated with it.

I had no direct contact with tech support by myself, but I haven't heard any complaints about it going around either. I guess it is adequate.

Previous to this solution, we used static code analysis using built-in IDE tools and plugins. SonarQube just centralizes the same thing and adds some extra layers to systemize and create a somewhat better pipelining for the quality analysis process.

IDE-related tools and plugins are still in use today, as first-in-line hints and helpers. SonarQube manages the quality threshold and it is part of the larger overall process.

The initial setup was not complex at all. There is default configurations out of the box in many ways. It was rather straightforward.

I have no advice on that part, as I'm not directly related to these aspects of the product myself.

Try it, get used to it, configure, and fine-tune it. Make it part of your everyday quality pipeline as gates necessary to pass before the green light to production deployment.

While annoying occasionally with its issue reports, it is actually an invaluable source of better knowledge and applying it in practice to your solutions.

Saves you bunch of headaches and debugging/fixing sessions at production, which is ten times as costly than using the help of this.

SonarQube and SonarLint were adapted as part of the CI development process, i.e., the developers who committed to high severity issues in the repository were immediately notified via mail/Jenkins.

An actual RuntimeException bug was discovered and immediately fixed by using SonarQube with CI.

SonarLint: It gives code smell check during development, via linting in IntelliJ (it helped with best practices and in discovering the early potential bugs).

SonarQube: Recording of issues over a period of time, with an indication of the addition in the new issues or the reduction of existing issues (which were fixed).

There is need for support for the additional languages and ease of use in adding new rules for detecting issues. Some issues that were detected after committing to the CSM by SonarQube were not displayed in SonarLint scans (hopefully this was fixed in later versions).

A single developer claimed that the SonarLint plugin caused performance issues on his IntelliJ IDEA. However, this issue was not encountered by the other developers.

There were no scalability issues but we did not use SonarQube/SonarLint on very large code bases.

They have very good documentation at the SonarQube site; during inquiries on possible purchases, the SonarSource team was very responsive.

We did not use a different solution in the past.

The initial setup was relatively simple (raising a dedicated VM server for SonarQube, configuring a Jenkins job to interact with the SQ server on several CSMs).

The SonarLint setup is extremely simple in IntelliJ.

We did not purchase a license (required for C++ support), but this option was considered.

The Java SonarQube version, which is free to use, was extremely helpful and I suggested to my managers that we purchase a license.

We did not evaluate other static code analysis solutions.

I would recommend adopting the usage of SonarLint at the very least for Java development since it is a very good tool for helping to ensure high code quality.

Quality Gate helps us to merge code that was not covered with tests.

• We can create a Quality Gate in order to fail Jenkins jobs where the code coverage is lower than the set percentage.
• We can review possible faults in JavaScript code.

We had some issues where the Quality Gate check sometimes gets stuck and it is unclear.

We had some stability issues where the Quality Gate check sometimes got stuck and it was unclear. This seldom happens.

There were no scalability issues.

The technical support team has experts on it. They are available on Twitter, Google Groups, and StackOverflow.

We did not use a different tool before this one.

The initial setup required unzipping it and having MySQL install. We then set up a couple of configuration files. There was no need for IT for this.

This is open source.

We are working in the banking sector, and our application code is quite large in terms of performance. Ranorex has helped us a lot to follow Java code conventions for writing performance oriented code.

It also has very good compatibility with continuous integration servers like Hudson and Jenkins.

It had changed the whole attitude of the developers of our team as they can see their code exceptions at compile time. With this, we have delivered a quality product to our stakeholders.

It would be great if it also covered XML code.

We have been using this solution in our Java web application for the last 18 months. We embedded SonarQube with the help of a SonarQube-maven plugin in our web application.

No issues encountered.

No issues encountered.

No issues encountered.

It's excellent as we get everything we need from the product.

It was somewhat complex as we have to integrate it with Apache Maven-2.2.1, and there is no listing of SonarQube version compatibility with Apache Maven.

We did it in-house.

It is quite an efficient product in terms of ROI.

Its is available on open to use license.

We did some R&D according to our product need and found SonarQube as a solution.

I would advise you to implement SonarQube if they are facing any performance related issues in their products.