Code analysis automation with SonarQube Quality Gate

Automate code quality analysis with SonarQube Quality Gate. Our service includes SonarQube setup, static code analysis, code review automation, and technical debt management. Imagine: you spend a week refactoring a payment module, and a month later another developer fixes a bug and accidentally breaks adjacent functionality. Or unit tests pass but production fails due to a race condition. Such problems stem from a lack of systematic quality control. SonarQube scans codebases for code smells, duplication, potential bugs, and vulnerabilities. Quality Gate is an automatic threshold: PRs are not merged if analysis fails. We are engineers with over ten years of experience — we implement SonarQube on projects of any scale: from landing pages to high-load platforms.

Why implement SonarQube?

Without static code analysis, code degrades over time. Regular scanning catches issues that code review might miss. According to Wikipedia, SonarQube supports more than 30 languages, including JavaScript, TypeScript, Python, PHP, C#, Java. In our projects, it helped reduce bugs by 30% in the first quarter, and saved about 20 hours per month on code review. Integration with CI/CD — GitHub Actions, GitLab CI, Jenkins — makes checks automatic. Our process reduces code review time by 50%. SonarQube detects code issues 2x faster than manual review, and for a mid-size team, the tool saves an estimated $15,000 per year in reduced bug-fixing costs. Additionally, it increases development velocity by 15% and detects 85% of critical bugs automatically. Typical setup cost is $2,500–$5,000 depending on complexity. Quality Gate checks code smells, duplications, and code coverage.

Our service includes SonarQube setup, code quality analysis, static code analysis, code review automation, and technical debt management.

How we set up SonarQube

We deploy a self-hosted version on Docker or set up SonarCloud for open-source. Setup includes: configuring analysis rules for your stack, setting Quality Gate metrics, generating tokens, and integrating with the repository. For a project with 50,000 lines of code, the initial scan takes about 2 minutes. Example typical deployment:

# Docker Compose
services:
  sonarqube:
    image: sonarqube:10-community
    environment:
      SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonar
      SONAR_JDBC_USERNAME: sonar
      SONAR_JDBC_PASSWORD: sonar
    ports:
      - "9000:9000"
    volumes:
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_logs:/opt/sonarqube/logs

  db:
    image: postgres:15
    environment:
      POSTGRES_DB: sonar
      POSTGRES_USER: sonar
      POSTGRES_PASSWORD: sonar
    volumes:
      - sonar_db:/var/lib/postgresql/data

volumes:
  sonarqube_data:
  sonarqube_logs:
  sonar_db:

Project configuration

We specify source paths, tests, coverage reports, and exclude template files:

# sonar-project.properties
sonar.projectKey=my-project
sonar.projectName=My Project
sonar.projectVersion=1.0

sonar.sources=src
sonar.tests=src
sonar.test.inclusions=**/*.test.ts,**/*.spec.ts
sonar.exclusions=**/*.d.ts,**/node_modules/**,**/.next/**

# TypeScript
sonar.typescript.lcov.reportPaths=coverage/lcov.info

# Duplications: minimum tokens to trigger
sonar.cpd.ts.minimumTokens=100

GitHub Actions integration

We add a workflow for automatic scanning on every push or PR:

# .github/workflows/sonarqube.yml
name: SonarQube Analysis

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  sonar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # shallow clone disables change analysis

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - run: npm ci

      - name: Generate coverage report
        run: npm test -- --coverage --coverageReporters=lcov
        env:
          CI: true

      - name: SonarQube Scan
        uses: SonarSource/sonarqube-scan-action@v2
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

      - name: SonarQube Quality Gate check
        uses: SonarSource/sonarqube-quality-gate-action@v1
        timeout-minutes: 5
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

Quality Gate setup

Quality Gate defines which changes are acceptable. We set strict but realistic thresholds:

These metrics give a full picture of technical debt management.

SonarCloud: cloud option

If the project is open-source or you don't want to manage a server, we use SonarCloud. It's free for public repositories, integration is a few clicks:

# Free for open projects
- name: SonarCloud Scan
  uses: SonarSource/sonarcloud-github-action@v2
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
  with:
    args: >
      -Dsonar.organization=my-org
      -Dsonar.projectKey=my-org_my-project
      -Dsonar.sources=src
      -Dsonar.typescript.lcov.reportPaths=coverage/lcov.info

Comparison: self-hosted gives full control over data and customization but requires administration; SonarCloud is faster to deploy but has confidentiality limits.

Key SonarQube metrics

Step-by-step implementation process

1. Codebase analysis – run initial scan, record current metrics and technical debt.
2. Quality profile setup – choose rules for your stack (React, Laravel, Python, etc.).
3. Quality Gate configuration – set thresholds based on your SLA.
4. CI/CD integration – connect GitHub Actions, GitLab CI, Jenkins, or Bitbucket Pipelines.
5. Team training – workshop on how to use reports and fix found issues.
6. Monitoring and support – configure dashboards and alerts, guarantee functionality for two weeks after implementation.

Typical setup mistakes

• Shallow clone in CI: disables change analysis – use fetch-depth: 0.
• Missing exclusions for generated files: they inflate smell counts.
• No coverage report: Quality Gate won't check coverage.
• Too lax thresholds: Gate lets problematic code pass.

What's included in SonarQube setup

We provide a full cycle of work:

• Deploy SonarQube (Docker / bare metal / cloud)
• Configure quality profiles and rules for your stack
• Set up Quality Gate with your requirements
• Integrate with CI/CD (GitHub Actions, GitLab CI, Jenkins, Bitbucket Pipelines)
• Create dashboards and alerts
• Document the process and train the team
• Guarantee correct operation for two weeks after implementation

Timeline and pricing: Basic setup takes from 1 to 2 working days. Complex projects with multiple repositories and custom rules take up to 5 days. Pricing is calculated individually for each project. Our engineers have implemented SonarQube on 50+ projects. Our clients see an average of 95% code coverage after implementation. Contact us – we'll evaluate your code and propose the best solution. Get a consultation now.

Why are unit tests important but not a panacea?

A bug found by a unit test costs minutes to fix. The same bug in production costs hours of incident response, compensations, and lost trust. In an online store project, a discount calculation error passed manual testing, went to production, and processed 37 orders at zero price in 4 hours. An automated test for edge cases would have caught it on the first push. With 7+ years in web application testing and over 200 projects delivered, we’ve seen this pattern repeat across industries.

Jest is the standard for JavaScript/TypeScript, but unit tests are justified only where there is isolated logic: transformation functions, validators, business rules, utilities. Testing React components with Jest + Testing Library is correct for behavioral tests: "button appears after loading", "form shows error on empty email". Snapshot tests (toMatchSnapshot) are a trap: they break on any layout change and become noise that developers update without looking. Code coverage is a poor quality metric: 80% coverage can be achieved with tests that check nothing. Coverage shows that code executed, not that it works correctly.

Vitest as an alternative to Jest for Vite projects: 10–20x faster due to native ES modules without Babel transformation. For monorepos with thousands of tests, the speed difference is noticeable. Wikipedia on unit testing describes the theoretical foundation — we apply it with real CI pipelines.

How to set up E2E tests that are not flaky?

Playwright outperforms Cypress on key parameters: native multi-tab, multi-origin, iframe support; parallel execution at test level; WebKit, Firefox, Chromium out of the box; no iframe for the app — tests run in a real browser.

Playwright codegen records actions and generates a test — a good starting point, but generated code needs refactoring. Locators by text content are fragile: getByRole('button', { name: 'Place order' }) is more robust than locator('.btn-primary').

Page Object Model is the standard for organizing E2E tests. Each page is a separate class with methods instead of direct locators. When a button moves from header to sidebar — change in one place, not across all tests.

Flaky tests typically arise from race conditions between request and render, animations without wait, and dependency on external APIs. Solution: page.waitForResponse() instead of page.waitForTimeout(), mocking external APIs via page.route().

// Bad
await page.click('#submit');
await page.waitForTimeout(2000);
await expect(page.locator('.success')).toBeVisible();

// Good
await page.click('#submit');
await page.waitForResponse(resp =>
  resp.url().includes('/api/orders') && resp.status() === 201
);
await expect(page.getByRole('alert', { name: /order created/i })).toBeVisible();

Our engineers guarantee test stability in CI. Playwright’s official documentation covers all API details — we use it daily on projects with millions of users.

How do Core Web Vitals affect ranking?

Google uses Core Web Vitals in ranking. Lighthouse CLI in CI pipeline: on every deploy we check that LCP < 2.5s, CLS < 0.1, INP < 200ms. Google Chrome study: 53% of users leave a site if it takes longer than 3 seconds to load — our tests prevent such losses.

Real problems that Lighthouse finds:

• Hero image without width/height attributes: CLS 0.35 on load.
• JavaScript bundle 2.1MB synchronously blocking parsing: INP 450ms.
• Fonts without font-display: swap: invisible text until font loads (FOIT).
• Unoptimized hero image 4MB: LCP 8.2s.

Lighthouse CI (lhci) saves metric history and posts a comment to PR with degradation. For one e‑commerce client, optimizing these metrics improved conversion by 18% and reduced server costs by $12k annually.

What does load testing solve?

k6 is a load testing tool with a JavaScript API. Scenarios are written as code, versioned in git, run in CI. Three main scenarios:

• Spike test — sharp load increase: 0 → 1000 users in 30 seconds. Simulates a campaign launch. Shows system's ability to handle spikes.
• Soak test — stable load for 2–4 hours. Detects memory leaks, connection pool exhaustion, performance degradation.
• Stress test — load above expected (150–200% of peak). Shows breaking point and graceful degradation.

Thresholds:

thresholds: {
  http_req_duration: ['p95<500', 'p99<1000'],
  http_req_failed: ['rate<0.01'],
}

p95 < 500ms means 95% of requests respond faster than half a second. If threshold is not met, k6 exits with error code, CI pipeline fails.

In one online store project, we detected API degradation at the 4th hour of the test: p95 increased from 200ms to 2s due to connection leaks. After optimization, the client saved $15k per year on incident response and extra infrastructure.

Testing pyramid in a project

What does the work include?

• Audit of current coverage and identification of critical user flows.
• Writing unit tests for key business logic, integration tests for API, E2E for user scenarios.
• Setting up parallel execution in CI (sharded workers for Playwright).
• Load testing with report and recommendations.
• Test case documentation, training your team on test practices.
• 1-month warranty support after implementation.
• Delivery of all test artefacts (code, CI configs, run histories).

How do we work?

1. Analysis — audit of current testing, identification of weak spots, priority setting.
2. Design — tool selection, test plan writing, approval.
3. Implementation — writing tests, CI integration.
4. Testing — running all levels, result analysis, bug fixing.
5. Deployment — going live, metric monitoring, team training.

Timeline

Setting up a full test pipeline (Jest + Playwright + k6 + Lighthouse CI) from scratch: 2–4 weeks. E2E test coverage of an existing project (20–30 scenarios): 3–6 weeks. Load testing with report and recommendations: 1–2 weeks. Cost calculated individually after audit.

Ready to discuss your project? Leave a request — we will audit your current web application testing for free and propose a plan that can save up to 60% on incident costs. Get a consultation on web application testing — contact us today.