What SonarQube is and why teams adopt it
SonarQube reads your source code without running it and reports problems it can recognise from patterns and data flow: likely bugs, risky constructs, security vulnerabilities, duplicated code and low test coverage. It supports many mainstream languages and presents results per project, per branch and per pull request.
Teams adopt it for two reasons. Engineering leads want a consistent standard that does not rely on every reviewer remembering everything. Security and compliance owners want evidence that code is analysed before release. Both are legitimate, and both fail if the rollout floods developers with thousands of old findings. As SonarQube consulting engineers, we spend most of our effort on gate design and tuning, not installation.
How we run SonarQube in production
Hosting choices
The self-managed server is a Java application backed by PostgreSQL, with search indexing that is sensitive to disk speed and memory. It is straightforward on a single well-sized VM or in Kubernetes with the official Helm chart, but it is stateful: you need an external database, regular backups, TLS, and a plan for upgrades between versions. The vendor’s cloud offering removes this burden. We help you decide using data residency, network access to your Git provider and who would be on call for the server.
CI integration
The scanner runs in your pipeline and uploads results. For a Maven or generic project, the call is short:
sonar-scanner \
-Dsonar.projectKey=payments-api \
-Dsonar.sources=src \
-Dsonar.tests=test \
-Dsonar.host.url="$SONAR_HOST_URL" \
-Dsonar.token="$SONAR_TOKEN" \
-Dsonar.qualitygate.wait=true
With sonar.qualitygate.wait the job fails when the gate fails, so the pull request status reflects it. The token comes from your secrets store, ideally something like HashiCorp Vault rather than a shared repository variable. Our CI/CD pipeline service and GitHub Actions page cover caching and parallel stages so analysis does not dominate build time. Shallow clones can break blame information and new code detection, so the pipeline fetches enough history.
Authentication and access
We connect SonarQube to your single sign-on, map groups to project permissions, and restrict who may change quality profiles or mark issues as accepted. Scanner tokens are scoped per project or per pipeline and rotated.
Rolling out without blocking developers
- Report only. Run analysis on every pull request with no failing status for a few weeks. Developers see issues on their own changes and get used to them.
- Measure the noise. Count which rules produce the most issues and the most dismissals. These are the candidates for tuning.
- Gate on new code. Enable a failing gate for new code only: no new blocker or critical issues, no new unreviewed security hotspots, a coverage threshold you already meet.
- Raise slowly. Increase thresholds one at a time, and only when the team consistently clears the current ones.
- Burn down legacy separately. Legacy findings get a time-boxed backlog owned by teams, not a merge blocker.
Tuning rules and findings
A default quality profile covers every rule the vendor ships, which is not the same as every rule that matters to you. We copy the default profile, disable rules that conflict with house style or frameworks, and lower severity for rules that are advisory. Generated code, vendored libraries and migrations are excluded. Security hotspots are different from vulnerabilities: they are code that needs a human judgement, so we define who reviews them and how fast.
Coverage targets deserve care. A high coverage number on new code is a reasonable guide, but chasing a percentage encourages tests that execute lines without asserting anything. We prefer a modest gate paired with review of what is actually tested.
Cost, capacity and day-2 operations
Cost has two parts: licensing, which depends on edition and lines of code analysed, and the operational cost of running the server. Check the current pricing model with the vendor rather than relying on assumptions. Operationally, we monitor database size, background task queues and disk, back up the database before upgrades, and follow the long-term support release unless you need a newer feature. Upgrades can reindex projects and take a while on large instances, so they are scheduled out of hours.
Failure modes we see
The usual failures are organisational. A gate is switched on for the whole codebase and promptly disabled after a week of blocked merges. Rules are left at defaults so reviewers see hundreds of style comments and stop reading them. Or the server is installed by one engineer who then leaves, and upgrades stall until the version is unsupported. We design around each of these: new-code gates, a short curated rule set, and a named owner with a documented runbook.
Honest limits
SonarQube is pattern and data-flow based. It does not understand your business logic, cannot detect most authorisation mistakes, and misses vulnerabilities that depend on runtime configuration. Some rules produce false positives, and some real issues need paid editions for deeper security analysis, so check what your edition includes before planning around it. It does not scan dependencies or images, which is what Trivy is for, and it does not read your Terraform, where Checkov is stronger. Treat a green gate as “no known problems of these kinds in the changed lines”, not “secure”.
When to choose something else
On GitHub with a security focus, CodeQL or Semgrep may give better security signal with less to operate. For a small team with one language, linters in CI are often enough. If your main concern is dependencies, start with a software composition tool.
Working with us
We typically deliver a pilot on two or three repositories, agree the gate with engineering leads, then roll out team by team. If you also need pipeline design, see our Azure DevOps consulting and managed DevOps services, or book a consultation.
Official documentation: www.sonarsource.com/products/sonarqube