SonarQube Server (formerly SonarQube) Reviews

Our software developers use SonarQube to catch any issues that can be found by using static code analysis. My understanding is that it checks the core complexity by evaluating the coding rules to make sure of things such as the correct classes are private.

The developers are rejecting the idea that this product is useful.

Before you even compile, it can catch known vulnerability issues or patterns.

Our developers have complained about the Quality Gates and the number of false positives that this product reports. Their older code is breaking and with the Quality Gate on the pipeline, they are not able to safely release at this point. This means that they have to add a lot of things to the whitelist, so there is room for improvement in this regard.

We have been using SonarQube for less than six months. We have not yet onboarded it for production.

I have not seen any problems in terms of stability, although it has not been onboarded yet. Once that happens, we may see more problems.

We have not tried to scale yet.

The initial setup involved downloading the open-source code and installing it in a container. 

I was responsible for setting up this tool in our company.

We are using the open-source version, which is available free of cost.

We evaluated other open-source products and found that SonarQube was the best one of the set.

This product is regularly updated by the open-source community, although the changes are often project-specific and may not help in the general case.

I would rate this solution a five out of ten.

I was using SonarQube to scan my code for vulnerabilities as part of the DevOps process.

The most valuable features are code scanning and Quality Gates.

The reporting can be improved. In particular, the portability report can be better.

I would like to see better integration with the various DevOps tools.

I was using SonarQube for between six and ten months.

The stability is good.

The community support is great. I have not had reason to contact the technical support team from the vendor.

The initial setup is straightforward. I would not say that it is complex and it can be deployed in less than 10 minutes.

I was using the Community Edition, which is available free of charge.

I evaluated other products including Veracode and I felt that SonarQube was the best product.

I would rate this solution a seven out of ten.

We use this SonarQube solution for code quality and as a basic security issues solution for our clients.

It has improved our options for offering products to our clients that can better meet their needs, lower costs, and improves code quality and basic security. 

Code analyzing is very valuable for detecting vulnerabilities but it has limitations.

With the aesthetic code analyzer or dynamic code analyzer, we would like to see zero vulnerabilities. This is actually currently not available with any available code analyzer so it is not the fault of this one product. We would like to see that the latest CVE (Common Vulnerabilities and Exposures) gets represented. This would be more useful but does not always happen. 

If we have more of an idea of the likelihood of zero vulnerabilities then the product is more useful for user communities.

The product is stable.

We use a centralized machine so scalability is not an issue. We have yet to realize a limitation.

We have little or no interaction with technical support.

We service client needs so we consider all solutions we are aware of and weigh the pros and cons for deployment with a specific client.

Implementation is easy and very straightforward. We do a POC with our client and based on that we make a comparison to the client's needs and available solutions. We compare that with any of the open source options and with any of the premium commercial tools. We go with the one that makes sense. But the implementation of this product is not complex especially as we have experience with it.

We do our own implementations for various clients. We do not need the assistance of another team.

Return on investment is enhanced code and security. The actual ROI is difficult to measure except that licensing a commercial product will cost more over the long term if this product is enough to meet the user's immediate needs.

The product is basically free, so implementation is the greater cost. It will cost in man-hours for deployment and resources, or in consultation. The licensing fee is negligible.

We are constantly evaluating other products. So it might be that we will go with Micro Focus, for example, or any other tool in the future. It depends on what is offered by the product and what fits the client needs and budget.

I would rate this product somewhere between six and seven. It works for many clients, but if the user need and application is super critical, people should go with commercial products like Micro Focus. If the deployment is less critical, they can go with that as SonarQube, or another open source software solution.

We have literally thousands of rules and they are of medium effectiveness. The problem is that most people bypass the rules or turn them off. But even that is information to us. The fact that they have to turn the rules off is as much value to us as the rules themselves.

Code coverage of tests is their most valuable feature. Code coverage is of no value if it's high, but if it's a low number then that's of great value to me.

I would like to see something around mutation testing included in SonarQube. I'd like to see some mechanism of quality which has real meaning. The problem in metrics is that they're correlated. I'd like to see how they can add a feature to detect genuine quality, instead of numbers that people can game. The number can be manipulated. There are a few ways to do this, and mutation testing is one of them.

I would also be interested in more security scanning.

Stability has never been a problem. It would have to be unstable for me to experience a problem, and we haven't. So it's good.

I don't really know how scalable this solution is, but I know we use it on thousands of projects, so it's probably good.

We have a pipeline. The pipeline currently runs 4000 teams through it, and all of them have SonarQube but usually with default rules. So that's pretty expensive. Now, we can't increase it because everything goes through it. We are evaluating what our best option is as we migrate our pipeline. We're migrating the pipeline and we're wondering what to do. If SonarQube did more security scanning, there's a good chance that we would use it more, in a different role. We're already using SonarQube everywhere, in some aspect.

It was years ago. They probably evaluated other solutions. 

We're evaluating the use of different solutions at the moment, but I've just withdrawn from that task.

In all the companies that I've worked with, nobody has ever had a problem with the initial setup. It takes time to set up. It's a big thing and you do it, but it's just a project.

We used people in-house to deploy. We have about 100 people in our pipeline maintenance team. SonarQube has not led to any significant increase in that number. It's just absorbed as a part of the cost. There are no dedicated staff working on it.

My advice is to focus on quality, not on tools. Work on the quality of your code and get a quality culture, but don't require the use of a tool. SonarQube is an okay tool. I'd suggest it as a default tool, but I wouldn't rave about it.

In all of my previous jobs, there has been somebody using SonarQube. They're usually very positive. I don't share that positiveness, but the reasons for that are that I don't believe you can have metrics of code quality based upon code analysis. I don't think it's possible for a computer to do it.

I don't rate any tool higher than a five or six, ever. JUnit is the only tool that gets a rating of ten. On a scale of one to ten, where ten is JUnit, I would rate SonarQube as about a five or a six.

Our primary use for this solution is to improve code quality and reduce technical debt.

This solution is part of our pipeline. We use GitLab for source control and Jenkins to build management. Jenkins kicks off our SonarQube scans, we use Checkmarx for static code analysis, UrbanCode Deploy, and UrbanCode Release.

Using SonarQube has helped us to identify areas of technical debt to work on, resulting in better code, fewer vulnerabilities, and fewer bugs.

The most valuable feature is that it lays everything out and breaks it down, making it very easy to find and identify issues.

SonarQube is really good for finding coding standards when people deviate from what we have set corporately.

I find that some of the graphs around the measures are too fancy, and they do not mean a whole lot to me.

The solution is a bit lacking on the security side, in terms of finding and identifying vulnerabilities. By comparison, we run the same piece of code through both SonarQube and Checkmarx and there is no comparison between the vulnerabilities that each finds. Checkmarx may find fifty, whereas SonarQube will only find fifteen or twenty.

I haven't had any issues with stability and we see it as quite stable.

The only time we had an issue was because we used a third-party plugin for it to integrate with another piece of software and there was a versioning issue. Other than that, we haven't had any trouble. We've had to integrate it with our LDAP and everything seems to run quite smoothly.

We are in the process of bringing on more projects right now. We are running probably forty-five right now, and we haven't had an issue.

We have approximately one hundred users. There are some developers, but mainly product managers who are using it to track the numbers, and see if they're moving in the right direction or not. We have it integrated with some of our IDEs that we use corporately, and the developers are using it to check for bugs before they check code in.

Right now it's a small subset of the company that is using this solution, and there are plans to increase it. They are already starting to onboard more teams. Our DevOps manager is starting to push it upon more and more projects.

We haven't really had any issues, so I can't speak much about technical support. There is also a large community out there who uses it.

We were not using another solution prior to this one. As we've evolved, this is one of the tools that we decided to go with.

The initial setup was fairly straightforward. It's well documented and the documentation is easy to read.

We rolled it out to one server that was used as a POC, which was later moved into a production environment. We then rolled out a second one for Dev to test doing upgrades, which we do on a regular basis. Every time a new LTS (Long Term Support) version comes out then we run an upgrade.

Only one person is required in order to handle the maintenance. It is easy to maintain.

We handled the deployment in-house.

I do not know the metrics, but they are being tracked for the projects. Better code is being built with fewer defects, bugs, and issues. Our DevOps manager is increasing its usage, so he definitely sees value in it. 

My advice for anybody interested in implementing this solution is to start with the community version and try it out. It doesn't take long to see value in it, and it's very straightforward, easy, and intuitive to use.

There are add-ons that are available for purchase that we have not tried, although we're quite content with what we have right now.

I would rate this solution an eight out of ten.

My primary use for this solution is to perform static code analysis.

The most valuable feature is the display of issues, like in Jira. That is very helpful for us to track our coding.

Improvements could be made in terms of security. 

I would like to see dynamic code analysis in the next version of the software.

The stability is good.

Scalability is good; we currently have five users but we will definitely be increasing our usage of this solution.

We have not required technical support for this solution.

This solution is not as easy to install as SonarLint. 

We are using the free, unlicensed version.

We evaluated other solutions including Cobra Static Code Analyzer, but we were not satisfied with their customer support in the open source community.

We advise all of our developers to have this solution in place. That way, whenever they are developing, the will get live tracking with respect to the quality of their code.

I would rate this solution a seven out of ten.

We primarily use this solution for code quality purposes. We have a CICD environment, without a lot of manual steps.

This solution figures out and tells you when there are code quality issues.

The quantification and reporting features are really good. 

The security portion of this solution needs to be improved. They do have a few rules, but I don't think that they are of much use because you cannot position it as a security scanner. I think that there is a lot more that can be done in the security space. I would like to see, for example, more security updates as part of the scan.

The reporting is good, but I am not able to download a specific report as a PDF, so downloading reports is something that should be looked at.

We would like to be able to perform differential scans for a few modules or a few lines, rather than for the whole source code each time. 

We have been using this for quite a number of applications, and its stability is very good. The scan time is very fast because it is a text-based scan.

We have not had any problems with scalability. We have a big organization with a lot of applications and all of our critical applications are on this platform. We are planning to increase the scope by adding less critical applications over time.

We were using some other products, but not on an enterprise level. There were several locally developed applications, but when we tried to consolidate all of these into an enterprise-level solution, we opted for this.

The initial setup was not complex. It is pretty simple and straightforward.

The costs for this application, for the kind of job it does, are pretty decent.

This product is good but it is not meant to be a single solution for all issues.

If you want to have your code scanned and timed then this is a good tool. If you want security to be part of it then you may need multiple tools. Overall, my advice is to use this tool in areas where it is strong.

I would rate this solution a six out of ten.

We're collecting code quality metrics.

We have the software metrics that SonarQube gives us, which is something we did not have before. This helps us work towards aiming coding standards to empower us to move in the direction of better code quality. SonarQube provides targets and metrics for that.

I like the dashboard it shows by default, where you can see things at a glance. At the same time, you can also drill way down and see a lot of stuff about your code, like complexity metrics, and things like that. It gives you a nice dashboard where you can just look at a birds-eye view.

We've been using the Community Edition, which means that we get to use it at our leisure, and they're kind enough to literally give it to us. However, it takes a fair amount of effort to figure out how to get everything up and running. Since we didn't go with the professional paid version, we're not entitled to support. Of course, that could be self-correcting if we were to make the step to buy into this and really use it. Then their technical support would be available to us to make strides for using it better.

On the other hand, there are published books available. However, the one problem I ran into is they were a little bit out of date. They're still very helpful, but we had to kind of translate from the previous version that was covered in the published books to what's actually available now.

An improvement I would like to see would be on the part of the authors to come out with a new edition or revision that covers some of the newer features of SonarQube and newer configurations. I'd buy a copy.

In terms of additional features, it's actually a very complete solution from what we have seen. Again, I would like the authors to revise their books. I think even ordinary people that are using the licensed model with direct support could walk through some different use cases, just from having been around the block a few times. There are enough things that the software does that this could be very beneficial. Even beyond the technical issues of installation, there are further use cases that could be helpful. For instance, how to get the big bang from the buck out of it.

We use C++ and a lot of Python. Another group in our company is using Java. SonarQube is more directly suited for Java, being almost built into it, whereas C++ requires some extensions. The Java group is using a newer version. We were kind of hoping to piggyback on theirs but SonarQube did not create newer versions of the C++ interfaces as open source. It's starts costing money so we haven't crossed that threshold yet. We haven't established a clear path.

I think if you're going to get the paid model, I get the impression it would do pretty much everything you need as far as metrics go.

A colleague of mine did some work looking at some plugins for Visual Studio and things like that, but they weren't going to work out, so we did take a look at some other options where they could have everything done on the desktop. Our solution in place now requires an infrastructure where it doesn't look at your code, but rather the code that you last checked in, which takes some levels of complexity that we've kind of built-in anyway. It's a little less intuitive how it works to the casual observer. It's set up now to where they don't have to know how it works, they can just go to the web interface and see it.

There are about eight programmers in our section of the solution. So we're kind of a smaller shop compared to some, but larger than many.

Certainly right now I think SonarQube is being underutilized, just because old habits die hard. If I had any say I would like to change that. We had coding standards in place, but they were written documents, whereas SonarQube takes that to another level and you had to look at the specification to see what you said you were going to do. It also tells you what the industry norms are, and whether or not you're meeting them. We have had some discussions about which we want to do. If we want it to happen automatically or if we want to go look for it again ourselves. I cast my vote in the automatic way because the research has already been done by the SonarQube community to come up with these roles, rules, coding standards, etc.

It wasn't done in a vacuum. The agile community has been beating on issues like this for a long time, and they're getting to a point that it's becoming a self-sustaining method.

They do have a lot of information on their website for the parts that they're offering free. We don't have licensing but there is a lot of information, it's just a matter of digging for it and you have to infer a few things. With the proper amount of agony we've managed to get there. There are some subtleties as far as configuration parameters. It does it one way, but we'd really like to do it a different way. Finding that magic incantation to flip that switch is not always in bold print so to speak.

Even for the freebie community which we're in, they haven't held back information. The information is out there to do some amazing stuff with it, but you've got to get your shovel and go dig it up.

We do have some other licensed software and when you look for information on their product, all roads lead to them and when you get there, you log in with your account that costs tens of thousands of dollars. SonarQube isn't like that. They don't hold the information back but you just have to go find it on their website by yourself.

We didn't have a previous solution other than paper systems that we never got in the habit of going back to referring to. We didn't switch, we started fresh.

The initial setup was complex because we were using the Community Edition. We did have some issues with the compatibility of the different components. For example, there is the server itself, but then you can plug in different packages, like the C++ package. We've also experimented a little bit with Python metrics, but unfortunately we don't have a project that's really under that control yet, to really get a feel for how that works.

Configuration issues were pretty complicated, but once we got things up and running, it's been extremely stable, it was kind of maintenance-free, now, although we have a time issue. Of the scans that it does, it could be somewhat time-consuming, so originally some of the developers would say, "Well we want to be able to do that on our desktop." I told them, "I don't think you know what you're asking for, here." But as an alternative, we have it set up with our continuous integration server, which we use in TeamCity by the way. In the middle of the night, it automatically runs a scan for them, while they're in bed at home asleep so their results will be ready the next morning. This way, whatever they have most recently checked in, they can see the results right there. And then it runs in the background so it doesn't matter how long it takes per se, it gets it done by the next time they come in. That's part of what continuous integration does, it does things for you that years ago people would do themselves, and never get around to it.

We spent a couple of weeks getting things figured out. I worked with an apprentice, who was kind of going through the motions.

We chose to use a Red Hat operating system for the base. It's running on a Red Hat 7 server which contributes to the stability from the foundation, then installed the actual SonarQube server on Red Hat. That's when we had the compatibility issues and so on when we started installing the scan engines on top of that. That's when things were not compatible with each other and we had to fall back and figure out why things weren't plugging and playing. However, they did have on their website a sheet that had a little chart that showed the compatibility between the different versions and once we discovered that I was able to see which version can work with which.

We didn't have to change the OS or the SonarQube's service itself, but the C++ extension. The version of the C++ extension we were using was not compatible with the Community Edition we had.

We've had a consultant at one point, not to look specifically at SonarQube, but rather at our firmer development processes as a whole. He's the one that played us towards SonarQube being a reasonable option. In fact, he was the one that helped us in finding the compatibility chart.

It's been mostly me doing the implementation on my own. I haven't been full time on it, but about half of my time is devoted to this. I do take some breaks and write some code and do some refactoring on occasion.

As far as time on SonarQube itself, only about a tenth of a person is devoted to this. It's part of an infrastructure. I have a whole family of virtual machines that do different things: build, test, etc..

We had looked at other code quality systems. We had looked at a number of them. I don't remember them all, but Clockwork was on that list. I think it comes down to picking one and getting used to how it works because they all do mostly the same thing. Some of them focus more on Java, some more on C++. I think Java seems to be the favorite. As far as what they can really do for you, there didn't seem to be any one of them that does ten times what another does. There were some differences, but not no show-stoppers that I recall. I guess the advice would be that one of several tools could do a good job for you, but you still have to manage it and manage the behavior that goes along with it.

I would rate SonarQube as a nine out of ten.

Once you start drilling down through the menus, it tells you a lot of stuff about your code in one view. That's really quite neat. That shows you a view of maintainability. They have a maintainability view that shows bubbles for all the different code modules, and yours is beside the bubble. This represents the amount of "code smells," which is actually kind of a common definition. The bigger the bubble, the more your code smells. This shows where more attention is needed or it's a bubble that's kind of drifting out of control.

I have one graph here where there are probably 50 bubbles. There's one axis that shows technical death, meaning the amount of work that it's going to take to get the smells under control. The other axis is lines of code, which is obviously a very common thing to look at. On this particular graph, there are a whole bunch of bubbles down in the lower-left corner, which means you have a lot of small manageable things. 

If you hover over the bubble, it tells you what module it is. How many lines of code. Technical death and manpower estimate, things like that.