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.
I have used this solution for about a year.
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.