SonarQube Reviews

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.

We use this solution in the development of our travel programs.

We use this program as a compliment to our security scans, in addition to Checkmarx.

The most valuable function is its usability. It uses a simple approach.

This solution finds issues that are similar to what is found by Checkmarx, and it would be nice if the overlap could be eliminated.

The plugins are not well documented.

This is a stable solution.

We do not have any problems with scalability.

We have approximately fifteen developers using this solution, on the Java site.

We have not needed to use the technical support.

We did not use another solution, prior to this one.

The setup is not complex. There are some issues during setup with the plugins because they are not well documented.

Some of the plugins that were previously free are not free now.

We are looking for how we can integrate several products. We are using static code analysis, we are looking into runtime code analysis, and of course, we have a web application firewall. The problem with all of these tools is that you need a lot of maintenance, and you have a lot of false positives. So, we have tried to find the best solution.

I would suggest trying the product. I like its useability because it has a simple approach.

We use this solution in conjunction with Jenkins, and we have a two-week deployment cycle.

I would rate this solution a seven out of ten.

Our primary use is for coding best practice management and quality. Aside from that, we also use it for security.

I'm getting involved in moving this solution forward and positioning it in our enterprise so I haven't gotten to the point where we're nailing down the configuration and release controls yet.

SonarQube has not yet had an impact on our organization. In the past, however, I've used it to control the security vulnerabilities and establish standards for API control.

There are two major use cases. One is to integrate it into the developers' workbench so that they can bench check their code against what will be done in the server-based audit version.

I haven't really done a comparative analysis yet.

We're in the process of figuring out how to automate the workflow for QA audit controls on it. I think that's perhaps an area that we could use some buffing. We're a Kubernetes shop, so there are some things that aren't direct fits, which we're struggling with on the component Docker side, nothing major.

Kubernetes is a container-based run-time that works with Docker in terms of container-based applications, so we're a microservice based solution. Microservices are contained inside these containers which are managed by a run-time called Kubernetes. Kubernetes comes out of a Google enterprise. It's used by organizations like Netflix and apps to do continuous development deployment and use integration and development. It means that your container has this application lodging, around which all of the user authentication, run-time controls, and communications integration are handled by Kubernetes.

For instance, an application doesn't really see its DNS at all. It's completely abstract in a way. It is layers away from a virtual hardware. What it does is abstract that patient component into a nice package of business logic that is managed in a dynamic container, which takes care of all the run-time and communication issues that normally become a lot of the configuration overhead of an application.

Once you get your Kubernetes environment behind and organized, that forms a very efficient way to introduce these microservices in a dynamic way and to easily integrate and upgrade components rather than applications. You're much more granular in terms of your release capabilities and much more efficient in terms of how it's released and managed.

I would rate this around seven out of ten, because it has what we need, and it's easy to use.

SonarQube stability is fine. I would rank it high on the stability side.

We're not going to test scalability. Our volume is not that heavy. For this organization, it's not serious in scope.

Our users include about 60 developers and two dozen QA. On the QA side, there will only be about five really using it. There will also be two people on security. In total about 60 or 70 enterprise-wide.

We are in the introductory phase and we will, later on, make this a part of our release process.

It's pretty straightforward. It's a very easy thing to get up and running. It's the workflow side that you have to be careful about. Make sure that you don't overwhelm everybody with a report with a gazillion lines. Your real gems are in a very small percentage of it. So that's the configuration side, and that's what we're working on now. I've found that you have to tailor SonarQube's power to the maturity of the organization. Otherwise, you get a report with 2,000 items in it and it's hard to find the ones that are critical. This leads to data overflow and analysis paralysis at that rate.

We did an evaluation in about two weeks, so it was pretty easy to do and that wasn't full-time.

We did not use an integrator, reseller or consultant for the deployment.

From experience, you should just size the scale of what you're trying to do to the maturity of the organization.

Our primary use case is to provide more coverage and reduce the reliance on code reviews alone. It also provides confidence and helps begin a path towards continuous improvement.

This has improved our process because it allows us to pick up on a lot of the smaller best practices that might otherwise be missed, in addition to ensuring code quality is not compromised between builds.

The most valuable features are the wide array of languages, multiple languages per project, the breakdown of bugs, and the description of vulnerabilities and code smells (best practices).

A robust credential scanner would be a huge bonus as it would remove the need for yet another niche product with additional cost, also gives the benefit of a single pane of glass view, although we still need white source bolt for 3rd part library scanning. The integration into docker builds could be better as pulling the latest version of the scanner, setting the path and then invoking the scan is an extra overhead to manage between versions of the scanner. An apt-get and scan start with the key passed as a variable would be a nicer implementation. Have not looked into SSL for the management page yet but hoping that goes smoothly.

We have only used this solution for a few weeks, but so far we have had no issues at all.

My impression of the scalability is good, as it appears that it can support a much larger number of projects than we have.

We have had no need to contact technical support.

I did not use another solution prior to this one.

The setup took a bit of work, but that was because we were combining Docker, Kubernetes, Azure Key Vault, and the Azure PaaS SQL Server.

We took care of the implementation in-house.

In terms of ROI, it is difficult to put a number against code quality. For the cost of hosting it, I would say very good if you do not have a solution to start with.

A self-hosted SonarQube on a Kubernetes cluster is very cost efficient if you already have the infrastructure and don’t need the premium features.

We evaluated the Checkmark Software Exposure Platform and Veracode, but they were expensive for a first go.

Our primary use case for this solution is security testing using the FindSecBugs plugin.

This has improved our organization because it has helped to find security vulnerabilities.

The most valuable feature is the FindSecBugs (Find Security Bugs) plugin, which finds security vulnerabilities.

The product's user documentation can be vastly improved.