SonarQube Server (formerly SonarQube) Reviews

We use the solution for the software scan and integrate the application, which is a dependency check for the scan. Our customers send us the already developed solution for functional tests and security scans.

Firstly, the integration with the pipeline is good. If you have the FICO pipeline integrated already, the depth of the pipeline will be good. Secondly, the solution is easy to understand. It took little time to learn and understand how to use data.

SonarQube has a community edition and an enterprise edition. The community edition is free, but the enterprise edition is not. In Thailand, we cannot use the enterprise edition because there are no resellers in Thailand. So we found many issues, like when you scan some source code, and if it's a problem, it appears the tool that we need to fix, but after our manual review, we found that we already did have something there. For example, it improves validation. But we did not get the input as it was already validated in another library. We called support and complained but have not received any information as we use the free version. We had to fix it on our own and could not escalate it to the tool's developer.

I have been using SonarQube for a year.

It is a stable product. I rate it seven out of ten.

I didn't have any scalability issues when we used the pipeline. But downloading the code and doing this again on a local laptop is quite slow, especially when somebody needs to try some code in a big and complex project. It takes about four to six hours. I don't know why it takes so long on a local laptop because it works fine in the integrated pipeline. For support in the integration pipeline, it could be nine or ten, but If it is on a local laptop, I think it would be only five.

As we are using the free version, there is no technical support available. But the documentation support is okay for us. We read it depending on the website, but we cannot escalate the issue to the SonarQube provider.

I used the Micro Focus Fortify, but the performance integration in the pipeline is faster in SonarQube. But in Fortify, the support is better as it is a commercial product, and we paid for it, so we can complain and get feedback in case of any issue. We complain if anything needs to be fixed, and they accept and fix it, but SonarQube does not have such a platform.

The initial setup is simple. It requires some security, but it's simple. It has some community to help with the technical information, and the technical team of the solution is also okay. It takes one or two hours to deploy. I was not involved in the integration in the pipeline, but I was involved in the solution installed on the local laptop.

I do not know about the pricing as I am using the community edition, which is free. But I compared the pricing with Sigma, and it is higher than SonarQube.

If you need the support of SonarQube, then use the enterprise version.

SonarQube should have a foundation in Thailand so that we can buy the enterprise version and get support. Secondly, SonarQube still does not support many languages, but I am still determining which ones. So if these two can be improved, it will be good.

I rate it seven out of ten.

We're using the enterprise edition of SonarQube. I'm the head of DevOps engineering and we are customers of SonarQube. 

The most important feature is the software quality gate. When that's implemented we're able to streamline the product's quality. The other good features are SonarQube's code quality scanning and code coverage. If we use it effectively, we can capture the software code bugs early in the software development. It also helps us to identify the test coverage for the code that we're writing. It's a very, very important feature for the software developers and testers. 

There is room for improvement in the code security space which is not as extensive as it could be. There are other products on the market which are much better in terms of code security scanning. I'd also like to see improvement in support which is quite expensive. 

I've been using this solution for six years. 

The product is stable although maintenance is a little cumbersome. 

The product is scalable but there are some concerns. You need to regularly do a cleanup of the lines of codes that are being scanned, otherwise the license will run out. We were not initially aware of having to do that. We have around 700 users in the company and we have three or four people involved with maintenance. 

There's a problem with the technical support because it's offered as a separate paid package and doesn't come by default with the license. Most other products in the market include  technical support with the software. There are various other products in the market, which are much better and offer support without any additional costs.

Licensing costs could be lower. We paid around 60,000 Singapore Dollars for our 20 million lines of code.

SonarQube is a very good tool for code quality.

I rate this solution a seven out of 10.  

SonarQube is a code-scanning tool that ensures people follow the right coding standard. It detects any memory leaks or unwanted functions that have been written so developers can optimize the code for better performance. We don't know too much about how our customers use SonarQube because we just set it up for them. We show them how the reporting works and what to do to fix common issues. 

SonarQube is one of the more popular solutions because it supports 29 languages.

SonarQube supports most database languages, like SQL queries, PL/SQL, etc., but some newer programming languages are not there. For example, it's missing some more popular languages like Apache Groovy. I would like to see some support for scanning these new popular languages.

I would also like SonarQube to be able to write custom scanning rules. More documentation would be helpful as well because some of our guys were struggling with the customization script. 

I've been using SonarQube for the past eight years or so. I am a DevOps consultant who helps the end-users set up their environments. My clients operate in various industries, including the service industry. 

SonarQube takes five to 10 minutes to install, and I train people on this technology, so I install it for them and teach them how to use it. On Linux, it maybe takes another five or 10 minutes, but it is straightforward.

We first try it out with a limited number of users, so four or five users will run it, but the report is shared with multiple users. The report generated will go to thousands of users. You run the report from the DevOps point of view, then share it with everyone.

I'm involved in the price discussions, so I'm unaware of the cost. However, I don't see any other competitors in the same space. There are one or two, but they're not popular. SonarQube is free for one user, so people can explore it, but if they need enterprise support, they can buy licenses, and we can go forward.

SonarQube is the only code scanning software I've tried, but I've also seen Nexus Scanner. However, it's not for binary scanning and so forth. It won't scan your source code. It's just an artifact scanner. 

I rate SonarQube eight out of 10. I always recommend SonarQube because it is also available in an open-source version, so people can understand the power of this tool and how it can help in an IT setting. 

Our primary use case of SonarQube is getting feedback on code. We are using Spring Boot and Java 8. We are also using SonarLint, which is an Eclipse IDE plugin, to detect vulnerabilities during development. Once the developer finishes the code and commits the code into the Bitbucket code repository, the continuous integration pipeline will automatically run using Jenkins. As part of this pipeline, there is a build unit test and a SonarQube scan. All the parameters are configured as per project requirements, and the SonarQube scan will run immediately once the developer commits the code to the repository. The advantage of this is that we can see immediate feedback: how many vulnerabilities there are, what the code quality is, the code quality metrics, and if there are any issues with the changes that we made. Since the feedback is immediate, the developer can rectify it immediately and can further communicate changes. This helps us with product quality and having less vulnerabilities in the early stages of development. 

This solution is deployed on-premise. 

One of the most valuable features of SonarQube is its ability to detect code quality during development. There are rules that define various technologies—Java, C#, Python, everything—and these rules declare the coding standards and code quality. With SonarQube, everything is detectable during the time of development and continuous integration, which is an advantage. SonarQube also has a Quality Gate, where the code should reach 85%. Below that, the code cannot be promoted to a further environment, it should be in a development environment only. So the checks are there, and SonarQube will provide that increase. It also provides suggestions on how the code can be fixed and methods of going about this, without allowing hackers to exploit the code. 

Another valuable feature is that it is tightly integrated with third-party tools. For example, we can see the SonarQube metrics in Bitbucket, the code repository. Once I raise the full request, the developer, team lead, or even the delivery lead can see the code quality metrics of the deliverable so that they can make a decision. SonarQube will also cover all of the top OWASP vulnerabilities, however it doesn't have penetration testing or hacker testing. We use other tools, like Checkmarx, to do penetration testing from the outside. 

SonarQube could be improved with more dynamic testing—basically, now, it's a static code analysis scan. For example, when the developer writes the code and does the corresponding unit test, he can cover functional and non-functional. So the SonarQube could be improved by helping to execute unit tests and test dynamically, using various parameters, and to help detect any vulnerabilities. Currently, it'll just give the test case and say whether it passes or fails—it won't give you any other input or dynamic testing. They could use artificial intelligence to build a feature that would help developers identify and fix issues in the early stages, which would help us deliver the product and reduce costs. 

Another area with room for improvement is in regard to automating things, since the process currently needs to be done manually.

Aside from other helpful features, the most important thing that SonarQube needs to do—the key feature—is to detect security vulnerabilities. The rest of the other features are helpful to the developer and the team to deliver the product faster, but security is a mandatory feature. 

As for additional features, SonarQube covers most of the languages, but there is still room for improvement covering the latest version of the tech stack—for example, Java 13. They're still improving, and they're focusing on SonarCloud nowadays. Currently, we aren't using all the top quality features of SonarCloud. I also think it would be helpful if SonarQube could integrate with Jira, a work management tool, or other communication tools, like Skype or Microsoft Teams, so that a bot could report directly to the developer. 

I have been using SonarQube for the past three years. 

The stability and performance of SonarQube are good. We use it on a daily basis, as part of our code development. 

As far as maintenance, it mainly happens when the product is being developed. There may be some features which can be enhanced, based on customer feedback and the tech stack, such as how we can improve performance of have a deployment with zero downtime. There are so many technologies coming, so many things happening, and there is always room for code improvements and the product we develop. Our top considerations are quality and security, which are being improved in a continuous process. There are many new features and enhancements coming in—for example, if you want to upgrade from the Java 6 version, then you can upgrade the tech stack, which will reduce the number of lines of code and improve performance. 

This solution is easy to scale. The instances in which we are deploying it are easy to scale because we are using it in production. We aren't supposed to deploy as part of the development, but the scalability feature is there because we are using Ansible, Kubernetes, and Docker. 

In our organization, there are currently around 25,000 people working with SonarQube. 

We also use Checkmarx and Snyk. One of the main differences between them and SonarQube is that they have dynamic testing and analysis, rather than static analysis. 

The initial setup wasn't a complex process. It was straightforward, and I had no issues. The deployment happened automatically and the pipeline was complete in three minutes. It depends on the scale of the project, the number of code repositories, the number of modules you are deploying, and all that. I would say deployment should take five minutes, maximum. 

We implemented this solution through an in-house team. Everything happens internally and we have our own internal tools, so there are no third-parties involved in development. 

I'm not too aware of the pricing because a different team covers that, but SonarQube has been on the market for a very long time, so I would guess the pricing would be decent. 

I rate SonarQube an eight out of ten. 

To those looking to implement SonarQube, I would advise you not to run it manually—integrate it with tools like Bitbucket and Jenkins, and make it automatic. If you change one line of code, the SonarQube should run automatically and give you the report. Don't go and run it manually and check the reports and all—it should run automatically to the entire code base, not to your particular module. So you need to configure that, as well as your project requirements and what code quality metrics will be achievable—like 85% or 95%—because you want code quality for a better product, without loopholes. You need to configure these things before starting to work with SonarQube. 

Our primary use case is to analyze source code for software bugs, technical debt, vulnerabilities, and test coverage. It provides an automated gated procedure to ensure that engineers are able to deliver great, secure code to production. 

We plug this process into our process right from the start enabling the IDE integrations so that engineers can scan their code before submission. Following on from that we run the scans on every change that has been submitted for review. 

This way we ensure that no core/fundamental issues are added to our codebases. 

It has helped many of the organizations that I have worked at to improve overall security, quality, and test confidence within the codebases. It also provides this in a speed efficient way. Engineers now feel much more proud of their solution as they gain confidence from these scans and their results. 

Engineers have also learned from the results and have improved themselves as engineers. This will help them with their careers. 

We are also able to get reports on our suite and generate a quality rating for ourselves utilizing this data and more. 

By far the quality gate controls. Without this, there would be no way to really utilize the power of this tool. We are able to automatically ensure that no code is delivered to production when it contains severe bugs or vulnerabilities. 

The tight integration to source control also helps us to keep the engineers in the loop with any follow-up actions for issues reported. 

Finally, the historical trend analysis gives us great insight into how we are improving based on our decisions, which are now driven by clear data.

It should keep up with newer technologies. As this is primarily open-source, it does require updates from the community. As such, there is sometimes a delay for new technologies to be covered by this too. 

Particularly around the languages that the webpages state they support. The big benefit of Sonar is that it handles so many different languages, problems, and static analysis in one place. 

When that one place has a low coverage for the most basic rules (OWASP top 10 for example) it starts to lose its value add. 

I have been using SonarQube for five years.

Good, I have not really had many issues with it. No major ones either. 

It all depends on where/how you are hosting it. The tool itself scales well. 

I have used Checkmarx and also tried a demo of Veracode. 

Checkmarx was far too heavy-handed and only handled security concerns for a VERY large price tag. 

Veracode is very good, however, the price vs a free solution was a deciding factor in many cases. 

It's very straightforward for a SaaS setup. 

For a self-hosted setup, it is documented well and fairly easy. 

We implemented in-house.

SonarQube will incur hosting costs. There are SaaS options available at competitive prices too. 

Self-hosting SonarQube is subject to its open-source licenses documented on their website. 

We also evaluated Checkmarx, Veracode and open source solutions specific to each programming language. 

Security analysis is a MUST. 

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 SonarQube mostly for code quality testing.

The integrations SonarQube provides with our software delivery pipeline are very seamless. The main benefit of using SonarQube in our organization was having a clean code with fewer static vulnerabilities within the application.

SonarQube could improve its static application security testing as per the industry standard. It would be really great if I could extract the overall report that I see in the dashboard.

I have been using SonarQube for a few years.

SonarQube is a stable solution.

Around 20 to 25 people use the solution in my team.

The solution’s initial setup is straightforward.

The solution can be deployed within a couple of days. We don’t need many people to deploy SonarQube. It is not difficult to maintain the solution.

We use the API call for SonarQube to integrate it into our development workflow. It's a continuous process for us to review the reports and remediate any findings we get from SonarQube. The quality gates and quality profiles are helpful in establishing the required gates and governance that we may need. SonarQube has impacted our team's productivity and code quality over time.

I would recommend SonarQube to other users evaluating it because it helps streamline some of the coding practices. The solution helps teams within the organization get into a good habit of writing clean code. The solution is helpful from a long-term sustainability standpoint.

I would recommend users to try out the open source version of SonarQube. If that doesn't suffice their needs, then they can go for an enterprise version.

Overall, I rate SonarQube an eight out of ten.

We wanted a coding standard. We used to get coverage using SonarQube, so once the coding coverage was more than 80%, it was only then we could get Jenkins to start the build. Otherwise, Jenkins would fail from the build process. SonarQube is the point at which we confirm the DI. It is in the JUnit test cases where the coverage of the source code was more than 80%.

The SonarQube dashboard looks great.

Currently, we are doing SonarQube's validations for external configuration via XML. It would be better if SonarQube provided a good UI for external configuration.

I've used SonarQube for three and a half years since I started using the product in 2020.

I have not faced any issues with stability so far.

If you know how to work with the solution, it is scalable. There should be some methodologies other than JUnit test cases. There should be some other area involving the code. Four or five developers are using SonarQube with JUnit test cases. They used to build in Jenkins because once Jenkins is built and SonarQube's code coverage is more than 80%, the build happens successfully. Otherwise, the build fails.

SonarQube's technical support is good.

Positive

Since I know how to install SonarQube, I had no issues. I don't think the installation is a big challenge because it's a one-time installation process. You wouldn't have to repeatedly install the solution.

The time taken to deploy the solution comes down to microservices.

In the configuration you maintain for the external file used to evaluate the point, the lines should be less than 80 characters long, and the page should have less than 900 lines. The function size should also be split such that the maximum length of one should be less than 30. That's the configuration we are doing with SonarQube. Also, the number of clients we wrote should be covered within the JUnit test cases. When using Mockito for some of the database functionalities like login and authentication, SonarQube will evaluate the test cases passing through it, even when considering Mockito as the data provider for those test cases. And SonarQube covers those test cases.

When it comes to external configuration, even if we're changing the format of one field, that should be accommodated everywhere in the file. Discrepancies there could make it take some time to install the solution. If they had a UI for the setup, that would be good. Though the XML configuration can be tough, it could be automated.

In the Trivandrum team, we do around one to three microservices, like authentication and inventory. Those are two of the main microservices that I handle. The remaining are handled by some other team from Chennai or somewhere. For us, the coverage with microservices is more than 80%. The authentication service and the inventory services have good coverage.

If somebody is looking for good coverage and a good standard code, they should start using SonarQube. When writing the code, they can ensure it is written properly and not missing any code. If there are many lines we are missing or ignoring from the code, there could be cases where vulnerability can happen from those lines. Before you submit any code to any client, you should ensure the code coverage is more than 80% of the application. I rate SonarQube a nine out of ten.