SonarQube Reviews

We use SonarQube to check for vulnerabilities and quality. 

The solution has helped us to find flaws in the Syntax and comply with requirements. 

I have found the most valuable features to be scanning for bugs or fixing the hotspot. These features have helped to improve the code quality. 

I think the code security can be improved. Code security should comply with the standard security list. 

I would like to see the feature of Compliance Reporting added to the solution.

I have been using this solution for two years. 

I would rate the stability a ten out of ten. 

About ten people in my company are using this solution. On average, we use this solution once in a week. 

We chose SonarQube due to its free community edition. After a while, when we will need more features, we will probably purchase the solution next year. 

I would rate the initial setup a ten out of ten. The solution is easy to install and use. It took us only a day to deploy SonarQube. We downloaded the solution and followed the setup process. We simply integrated this solution with Azure DevOps. The maintenance of this solution is handled by one person from the database team. 

We implemented the solution through an in-house application developer. 

This solution is simple to use and can be quickly deployed. I would rate the solution an eight out of ten. 

The product needs to integrate other security tools for security scanning. 

I have been using the product for a year. 

SonarQube is scalable. My company has 50 users. 

I rate SonarQube an eight out of ten. 

It serves as our primary tool for static code analysis, addressing various aspects such as code duplication, code smells, and security concerns. It stands out as an all-encompassing solution and it excels in security analysis and offers robust features for code optimization and duplication detection.

Through SonarCloud, we gain insights, especially in a microservices environment with product-based products. It provides valuable guidance in scenarios where I might not be well-versed in optimizing security for a particular service. It highlights areas for improvement, such as ensuring proper handling of headers and advising on changes needed in the codebase. Moreover, it offers suggestions for code enhancements, pointing out more efficient methods in languages like JavaScript.

Recently, they introduced support for mono reports and microservices, which is a noteworthy development as it provides a more detailed view of each service. Now, we can easily assess which services have more code and identify areas with potential issues. This addition has proven to be the most beneficial feature for our current use case.

There's room for improvement in the configuration process, particularly during the initial setup phase. Setting up features like mono reports can be challenging, and the existing documentation could use improvement in providing clearer instructions. I found myself needing to engage with support multiple times to navigate through certain aspects. Additionally, it would be beneficial if it could streamline the integration process for new features. Enhancing documentation on how to integrate these features seamlessly would go a long way in improving user experience. The introduction of an auto-commit functionality would be a valuable addition. Some other tools offer this feature, allowing for the automatic creation of pull requests to address identified issues. This functionality significantly reduces the manual effort required.

I would rate its stability capabilities ten out of ten.

I would rate it a ten out of ten because I haven't encountered any scalability-related issues. In my current company, we have around fifty users distributed across various organizations, including some smaller groups with around five to six individuals. In my previous job, the user count was higher, ranging from one fifty to two hundred people.

I find the support to be effective. Upon reaching out to them, they responded promptly, actively engaged in addressing the issue, and made efforts to resolve it. I would rate it ten out of ten.

Positive

We have experimented with other solutions simultaneously, but we consistently find this one to be more effective. It possesses an all-in-one capability, which is noteworthy. Typically, one might need separate software for security, another for static code analysis, and so on, but having everything in a single platform makes it advantageous.

The initial setup was challenging. Incorporating an auto-commit function would be a valuable enhancement and would markedly decrease the need for manual intervention and effort. I would rate it seven out of ten.

The deployment process is typically quick, taking about twenty to thirty minutes. For regular services, the setup is straightforward, involving the creation of a client account, installation of the SonarCloud app in GitHub, and linking it to the specific repository. In the case of microservices, the process involves having the GitHub action ready. Once the action is prepared, it's a matter of pasting it, and everything is set up. Updating and creating projects in SonarCloud are the next steps for microservices. The platform also offers the option to create multiple projects simultaneously. The main challenge users encounter when setting up microservices architecture on SonarCloud is the need to create their own GitHub action. The issue arises from inaccuracies in the GitHub action documentation provided by SonarCloud. Ultimately, to resolve the problem, users often have to create their own GitHub action independently, as the documentation does not offer a straightforward solution. Typically, a single individual, whether a DevOps professional or a Cloud Engineer, is sufficient for managing it.

The return on investment is positive as it not only aids in identifying issues but also helps developers gain a better understanding of the code. When facing particular challenges, developers often introspect and subsequently modify their coding practices, making it highly beneficial in that regard. I would rate it ten out of ten.

I would rate the price an eight out of ten because it's reasonable. While not extremely cheap, it aligns well with market standards and offers good value. It's an all-inclusive package where you pay a fixed price.

We examined options such as AWS CodeGuru, Snyk, and DeepScan recently. Despite considering the possibility of switching to another tool for a specific product, none of these options seemed suitable, leading us to retain our current choice.

Opting for SonarCloud is advantageous as it offers a complete package, including static code analysis, security assessments, and code optimization, all within a single tool. Overall, I would rate it nine 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.

SonarCloud is used for application security testing. The use cases you can bring into the pull request level, you can eliminate the problem into the developer's feature branch itself. The largest use case is if developers are writing a code and if the code has any vulnerabilities or problems, you can receive the feedback at the pull request level.

The most valuable features of SonarCloud are the ability to discover vulnerabilities, security weak points, security hotspots, and all the feedback that comes into the feature branch. You can deploy the code with the security, you can eliminate the problem at the developer level rather than identifying the problem in the productions.

Having SonarCloud on the cloud there is no maintenance because they patch everything. It's easy to maintain, but it may be a problem with very large organizations because of some of the false-positive and you may need to be very cautious on very large enterprises. The solution is best suited for startups and mid-size companies.

It is supporting the mono and multi report and overall they're always improving. Initially, they did not support the mono report, now they started supporting the mono report approach, when is a benefit.

SonarCloud can improve the false positives. Sometimes the gates sometimes act a little weird. We then need to manually go and mark the false positive. 

I have used SonarCloud for approximately five years.

SonarCloud is very stable, it does not go down.

Having SonarCloud in the cloud gives us a lot of scalabilities.

We have approximately 100 to 150  developers and others at the management level using this solution. Now we educate at the management level. Even they take a look and they see what gates are failing because it's a nice UI. Anybody can easily see what's going on with the solution, in terms of many aspects, such as security and reliability.

SonarCloud has community support, but not technical support. They frequently reach out to us and ask if we are happy or if we have any problems, if so, they can escalate it to the account manager. They have good support.

The price of SonarCloud is not expensive, it goes by the lines of code. 1 million lines per code are approximately 4,000 USD per year. If you need 2 million lines of code you would double the annual cost.

My advice to others would be to work out the appropriate gate that is meaningful and if your project has many problems. You can set the bar on high, in a way the gate forms are the same and you can lower the threshold as you progress.

I rate SonarCloud an eight out of ten.

We do a lot of development. We were previously doing it internally, and then we hired a couple of development partners. So, day in and day out, a lot of changes were happening. We wanted to ensure that whatever changes happened, they undergo some level of quality assessments. That was one of the reasons why we wanted to use it. 

We have started looking into it from the information security side, but it is being used by the core development team.

We are using the Community edition. So, we don't have to incur any licensing costs. This is the best part.

There is no automation. You need to put the code there and test. You then pull the results and put them back in the development environment. There is no integration with the development environment. We would like it to be integrated with our development environment, which is basically the CI/CD pipeline or the IDE that we have.

It's a stable solution.

It is not scalable if you have a bigger workload. Because it is a Community edition, it has its own restrictions and limitations in terms of the number of lines of codes.

We have 15 to 20 people who are using it.

We don't have any experience with them. We don't have any AMCs, and we don't have any technical support.

It was easy, but because we were using it for the first time, it took some time. I would rate it 3.5 out of five in terms of ease of setup.

We deployed it in-house. In terms of maintenance, there is only one person who is taking care of SonarQube as a platform or the services that are provided by SonarQube.

We are using the Community edition of SonarQube.

For a small setup with less number of applications, it is okay because it is easy to deploy and manage with a simple console. When the number of lines of code is high, it takes time, and you have to spend a lot of time in terms of getting the right results.

I would rate it a seven out of ten.

I have it integrated with our continuous integration server. On a scheduled basis, typically in the middle of the night, it'll do performance scans so that the results are available and viewable by the developers on the website. The scans are done automatically by using a continuous integration server, which is TeamCity.

We are using version 5.6.6. It is a very old version, but that's what we've been using. We haven't gotten around to updating it.

I like that it's easy to navigate not just in terms of code findings but you can actually see them in the context of your source code because it gives you a copy of your code with the items that it found and highlights them. You can see it directly in your code, so you can easily go back and make the corrections in the code. It basically finds the problems for you and tells you where they are.

The learning curve can be fairly steep at first, but then, it's not an entry-level type of application. It's not like an introduction to C programming. You should know not just C programming and how to make projects but also how to apply its findings to the bigger picture. I've had users who said that they wish it was easier to understand how to configure, but I don't know if that's doable because what it's doing is a very complicated thing. I don't know if it is possible to make a complicated thing trivially simple.

They could improve their documentation. There were some books written about it, but even when we first started using it, the books were out of date. It's more of a plea to some of the authors who have become experts in using it to revise their books. I'd buy a copy of it. SonarQube does a good job of supporting the open-source community, but some of the documentation tends to lag behind. That's not unique to SonarQube. It gives an opportunity to those who have taken the time to learn about it to author books and become resident experts or community experts. It'd be nice if some of those guys made another edition to support the open-source efforts that are there.

In terms of features, at this point, I don't have any requirements. We've been growing into it slowly, and we haven't really exhausted what it already has. When and if we get to a point where we are aggressively applying what it's telling us, we may reach a point where it's like, "If it could tell us this as well, that'd be nice." We haven't reached that point yet. We haven't listened to all of the advice that it's giving us now.

It has been a couple of years.

Any lack of stability is because it's being expanded and updated pretty much constantly. We haven't experienced any crashes or bugs. We do have an opportunity here coming up within the next few weeks of revisiting some of the ways we do things there.

It is definitely scalable. We plan to increase its usage.

Since we're using the open-source components, we use web searches and online resources. Once you get a little used to their website, they have a lot of information. The support, even for an older version, is pretty good. I've been able to find workable solutions. You just have to do a little searching.

We don't have stability issues. It hasn't crashed since we got it up and running, but there are some configurations or different options you can apply when you're scanning. So, you have to learn its language, and the information is available if you search the web.

Way back in the past, we used other static analysis tools like PC-lint or Gimpel Lint. I still have plans to resurrect some of that, but I'm of the mindset that the more opinions you get about your code, the better off you are. You get to look from different angles with different tools. In terms of the automated tool, SonarQube was the first one we had for getting into the DevOps generation of stuff.

We did have some issues, but they were because we didn't understand the relationship between different flavors. You've got the server, and the SonarQube service itself provides an HTTP type input. There are also versions of the scanners for different tools we're using, which are typically C++. We started with a mismatch of that. It may have been the server and the scanner, which runs on your client workstations. We had a mismatch of versions. After we dug into it a little bit and realized that was the problem, it was pretty straightforward. The setup from there was pretty trivial. 

You do need to know how to use a database. I most certainly use MySQL just because it's easily available on a minimal Linux install, CentOS. It's a Red Hat 7. It's BaseOS, a minimal install. It probably needed Java and a few tools that are fairly common. If you know how to set up a MySQL database, you can do it. If you know how to set up Java on Red Hat, which is pretty straightforward other than the fact that some path issues come into play, but that's just part of the game. Once you do that, it installs pretty easily.

We did have a consultant. He was looking at our overall engineering infrastructure, things beyond SonarQube. He was helpful in finding out, or pointing out, that it was the issue with the revisions. The versions of the different pieces weren't matching up. He did help with that, but in terms of putting it in, I did the validation work for validating the installation process and reproducibility for future users in case I leave the company and they need to recreate it. They've got the documentation to do so. So, I did all that. For an application of its complexity, it was fairly straightforward once we resolved the version issue.

Its deployment and maintenance can be done by one engineer.

We're using an older version because it is the open-source flavor of it and we can continue using it at no cost. We're not paying any licensing at all, which was another factor in choosing this route so that we can learn and grow with it and not be committed to licenses and other similar things. If we choose to get something else, we have to relearn, but we don't have to relicense. Basically, we're paying no license costs.

We did look at a lot of other ones. Some of the names I actually can't recall. There were code quality analyzers out there besides that. We did review them and settled on this one because it's very widely used, and the open-source capabilities are pretty well-supported to where you can use it without obligation. None of them are trivial to set up and use because they are doing a very complicated process. They all have their different ways of going about things, but you've got to understand any one of them. We picked this route.

You have to be willing to invest. For any tool of this magnitude, if you're going to say, "Well, we want to do the least we can possibly do and see what's the least we can get by with," you'll get the least possible benefit. My recommendation is that you do the opposite. You should consider everything it's telling you. You may not want to fix everything, but you should be aware of everything that's showing in your code. After that, you have the opportunity to look at your whole development process and just the way you do things and go back to your roots and look for ways to change things at the beginning that can have an impact. You have a big impact on the output of things towards the end, but maybe change the way you start things. Instead of trying to get the least that you can get with the least amount of effort, partner yourself with it as much as possible.

I would rate it an eight out of 10.

SonarQube is used for in-production scanning of applications. We are only doing unit testing to improve the overall quality of the code.

The developers have responsibility for unit testing, but it is very important that we check what they have been doing. SonarQube allows us to see the result directly in the pipeline.

We had some issues scanning the master branch but when we upgraded to version 7.9 we noticed it does scan the master branch but we had to do a workaround for it to happen. This process could be improved in a future release.

What we are seeing is for some of the Javascript projects SonarQube is not reading all the files. We had to manually configure it to accomplish what we wanted. However, we probably needed some documentation that we did not have that explained this process.

In an upcoming release, it would be beneficial to have the ability to use multiple applications under one project, and if we want to scan one of the applications we can just switch to that application, this would be really helpful.

I have been using SonarQube for approximately two years.

The solution is scalable. 

We have plans to increase the number of users using this solution because we have approximately 3,000 applications but only 200 are being used.

There are a lot of people using this solution in my organization because they are able to scan directly from their IDs.

We have worked with the support from SonarQube and we have had good experiences.

The initial setup was simple. When we did the upgrade and it took our team approximately two hours.

Our internal team did the implementation of the solution.

We are using the community version of the solution and we plan on purchasing licenses for the upgraded version soon. There is a limitation on how many lines of code can be scanned and this is why we are going to purchase a license for an increased amount.

SonarQube is a very nice tool and people can learn to code better from the analysis it provides. We needed to make sure our code is maintained properly and has high quality and this tool helped.

The solution has made the developers have more confidence in their code because from the scanning they can fix bugs and problems easily.

I rate SonarQube a seven out of ten.