SonarQube Server (formerly SonarQube) Reviews

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.

We use it to check the code quality of our software.

We've configured it to run on each commit, providing feedback on our software quality. The solution works quite well remotely.

We would appreciate having PNC checking, though that's only available in a more expensive license type.

There is also room for improvement in the installation process.

I have been using this solution for a couple of years.

It is a stable solution. So, no issues with stability.

We haven't had much requirement for scalability. We had a single-node instance, and that is sufficient for our needs.

We have around 13 developers using this solution. 

Another department handled the installation. We only had one issue related to the number of available files. To perform the analysis, you have quite a lot of available file handles, so we had to increase that limit.

However, maintenance is actually quite easy. It requires a couple of people.

We used some main code quality tools before, along with certain plugins. SonarQube is better due to its integrated nature and easier management. There is no hassle to keep everything up to date.

I would definitely recommend using the solution.

Overall, I would rate the solution an eight out of ten. While I'm satisfied with the product, there's always room for improvement.

I use the solution for static code analysis and to identify vulnerabilities and code smells.

All the features of the solution are quite good.

New plug-ins should be integrated into SonarCloud to give more flexibility to the product.

I have been using the solution for the last couple of years.

I rate the stability an eight out of ten.

I rate the product’s scalability as an eight out of ten. Currently, not many teams are using the product. We are trying to increase the number of users.

The first time, the initial setup was complicated. It got easier once we got used to it.

The deployment took around one to two hours.

The solution is cheaper than other products.

We have not been able to use the product extensively. I would recommend the solution to others. It'll really help the developers to increase their development speed. Overall, I rate the solution an eight out of ten.

Our use case of SonarQube is to analyze code quality and to implement quality dates in our build pipelines.

The ability to tweak the rules and feed them into our build pipelines so that they can become an integral part of those pipelines is a valuable feature. This product works really well, the integrations and pipelines are good.

SonarQube currently requires multiple tools. I'd like to have the ability to use one tool overall. 

We've been using this solution for a few years. 

The solution is stable. 

The solution is scalable. 

We pay a very reasonable, annual licensing fee. 

My recommendation is to just go with this out-of-the-box rule set first. Don't try to tweak them and learn what they mean. First learn what the alerts mean and then slowly tweak it to your specific use cases.

I have used it to test clients' websites. After testing, it gives a deep overview of website bugs and issues. 

A good point about SonarQube is that it gives you the solutions to resolve your issues. At times, I find the blocker (during times of emergency code deployment) doesn't allow the code to be checked-in to the repository unless the violations are fixed, which should enable the user to bypass the number of lines that should be part of the written method. 

It improved our website's look and feel. 

We consider it a handy tool that helps to resolve our issues immediately. 

It is a good tool for evaluating technical debt and introducing junior developers to codification standards and good practices. There is an amazing code quality application that defines coding standards. 

The tool is pretty much useful for a technical lead to reduce his efforts in reviewing the codes. The tool has integration with several languages. 

SonarQube is a Code Quality Assurance tool that collects and analyzes source code and provides reports on the code quality of your project. It combines static and dynamic analysis tools and enables quality to be measured continuously over time.

The solution's most valuable features are its:

• Code quality
• Release quality code
• Code security
• Security analysis

SonarQube empowers all developers to write cleaner and safer code. You can grow as a developer.

Integrations Analysis results are right where your code lives.

It works well with GitHub.

It should be user-friendly. I keep looking for improvements after every update. 

PeerSpot users give SonarQube an average rating of 8 out of 10. 

SonarQube is most commonly compared to Checkmarx: SonarQube vs Checkmarx.

The SonarQube brand is trusted by many teams and it has been validated. It is one of the most recommended free application security testing solutions. 

SonarQube is really a good tool for SAST with seamless integration to your CI/CD pipeline. We have used it on our website and had good results.

I have been using SonarQube 8.9.7 for a long time (since we had some issues in our software dealing with many critical issues that needed to be resolved for clients). 

I recommend SonarQube as it is beginner-friendly and can resolve your issues with the proper usage of your website.

The dimensional stability of the impression materials depends on the time elapsed between the completion of the impression and their casting, thus storage time is critical to obtaining reliable casts.

Beyond listening, customer service is doing everything in one's power to efficiently and accurately serve each customer.

Positive

We did use another solution, however, we found issues such as:

• Ineffective time management
• Lack of instant communication
• Not receiving timely feedback
• Not receiving clear instructions or expectations
• Share time management apps and resources for students
• Utilize educational technology (“EdTech”)
• There's also a need to increase peer review

The solution is easy to do and understand. It's not complicated and it's easy. It's a relatively straightforward process.

According to conventional wisdom, an annual ROI of approximately 7% or greater is considered a good ROI for an investment in stocks.

The primary use case of this solution is for static code analysis, and benchmarking our code standards according to our preferences. 

Our builds process through SonarQube and if it passes the required set of requirements we have set, it will then go through to production.

The most valuable features are the segregation containment and the suspension of product services. Also, the library that SonarQube covers is good.

The library could have more languages that are supported. It would be helpful.

There are a few clauses that are specific to our organization, and it needs to improve. It's the reason that were are evaluating other solutions. It creates the ability for the person who releases the authorized release, which is not good. We would like to be able to expand on our work.

MicroFocus, as an example, would be helping us with that area or creating a dependency tree of the code from where it deployed and branching it into your entire code base. This would be something that is very helpful and has helped in identifying the gaps.

It would be great to have a dependency tree with each line of your code based on an OS top ten plugin that needs to be scanned. For example, a line or branch of code used in a particular site that needs to be branched into my entire codebase, and direct integration with Jira in order to assign that particular root to a developer would be really good.

Automated patching for my library, variable audience, and support for the client in the CICD pipeline is all done with a set of different tools, but it would be nice to have it like a one-stop-shop.

I would like to see improvements in defining the quality sets of rules and the quality to ensure code with low-performance does not end up in production. We would also need the ability to edit those rules.

I have been using SonarQube for approximately two years.

The stability is good. 

The branch advanced analysis pull request declarations, they are good and highly valuable, but they are not part of the free edition. They are only available as part of the licensed one.

Currently, we have 1.2 to 1.5 million lines of code. Certainly, if that increases, so would the costs expediently. 

We have 50 developers' licenses.

There is quite a bit of maintenance that is needed. We have a couple of people from our operations team to do the maintaining.

It is integrated with our CICD department and is being used extensively.

We do have plans to increase the usage of SonarQube.

We have used open-source origins of the tools.

PCI is an open-source solution that we used before, and we used Snyk as well.

The initial setup is straightforward.

We did not use a vendor team, it was done by us.

The developer edition is based on cost per lines of code.

Now we are looking for a more mature solution and evaluating other products. We want a complete code analysis platform that is more mature.

We will either go with the paid Developer active license or solutions such as Checkmarx or MicroFocus.

The community edition is quite informative for engineers. The actual code analysis is not conducted on the GitLab flow, but the build pipeline would show the core quantity steps which is part of the criteria.

The trial gives you a way to implement the POC and check if it can be integrated with your own stack. Once the trial expires, you can continue with the same setup for getting the license.

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.

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.