Налаштування SonarQube для аналізу якості коду сайту

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Налаштування SonarQube для аналізу якості коду сайту
Середній
від 1 дня до 3 днів
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    956
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947

Уявіть: ви тиждень рефакторите модуль оплати, а через місяць інший розробник виправляє баг і випадково ламає сусідній функціонал. Або юніт-тести зелені, але в проді падає через гонку даних. Такі проблеми — наслідок відсутності системного контролю якості. SonarQube сканує кодову базу на запахи коду, дублювання, потенційні баги та вразливості. Quality Gate — автоматичний поріг: PR не мержиться, якщо аналіз не пройдено. Ми — інженери з досвідом понад десять років — впроваджуємо SonarQube на проектах будь-якого масштабу: від лендінгів до високонавантажених платформ.

Чому варто використовувати SonarQube?

Без статичного аналізу код з часом деградує. Регулярне сканування виявляє проблеми, які code review може пропустити. За даними Wikipedia, SonarQube підтримує понад 30 мов, включаючи JavaScript, TypeScript, Python, PHP, C#, Java. У наших проектах він допоміг скоротити кількість багів на 30% за перший квартал, а економія часу на code review склала близько 20 годин на місяць. Інтеграція з CI/CD — GitHub Actions, GitLab CI, Jenkins — робить перевірку автоматичною.

Як ми налаштовуємо SonarQube?

Ставимо self-hosted версію на Docker або розгортаємо SonarCloud для open-source. Налаштування включає: конфігурацію правил аналізу під ваш стек, налаштування метрик для Quality Gate, генерацію токенів та інтеграцію з репозиторієм. Приклад типового розгортання:

# 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:

Конфігурація проекту

Вказуємо шляхи до вихідних кодів, тестів, звітів покриття та виключаємо шаблонні файли:

# 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

# Дублювання: мінімум токенів для спрацювання
sonar.cpd.ts.minimumTokens=100

GitHub Actions інтеграція

Додаємо workflow для автоматичного сканування при кожному пуші або 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 відключає аналіз змін

      - 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 і як його налаштувати?

Quality Gate визначає, які зміни вважаються прийнятними. Ми виставляємо жорсткі, але реалістичні пороги:

Умова (для нових рядків) Поріг Статус
Coverage < 70% FAILED
Duplicated Lines > 3% FAILED
Maintainability Rating < A FAILED
Reliability Rating < A FAILED
Security Rating < A FAILED
Security Hotspots Reviewed < 100% FAILED

Ці метрики дають повну картину технічного боргу.

SonarCloud: хмарний варіант

Якщо проект open-source або ви не хочете адмініструвати сервер, використовуємо SonarCloud. Він безкоштовний для публічних репозиторіїв, інтеграція — у кілька кліків:

# Безкоштовно для відкритих проектів
- 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

Порівняємо self-hosted vs SonarCloud: self-hosted дає повний контроль над даними та кастомізацію, але потребує адміністрування. SonarCloud швидше розгортається, але має обмеження щодо конфіденційності.

Ключові метрики SonarQube

Метрика Опис Типовий поріг
Coverage Відсоток покриття тестами ≥ 80%
Duplications Дубльовані блоки коду ≤ 3%
Code Smells Запахи коду (складність, когнітивна складність) Рейтинг A
Bugs Імовірні баги (null pointer, невірні умови) 0
Vulnerabilities Потенційні вразливості 0
Security Hotspots Потребують ручного review 100% reviewed

Поетапний процес впровадження

  1. Аналіз кодової бази — запускаємо перше сканування, фіксуємо поточні метрики та технічний борг.
  2. Налаштування профілю якості — підбираємо правила під ваш стек (React, Laravel, Python тощо).
  3. Конфігурація Quality Gate — встановлюємо пороги на основі ваших SLA.
  4. Інтеграція з CI/CD — підключаємо GitHub Actions, GitLab CI, Jenkins або Bitbucket Pipelines.
  5. Навчання команди — проводимо воркшоп з роботи зі звітами та виправлення знайдених проблем.
  6. Моніторинг та підтримка — налаштовуємо дашборди та алерти, гарантуємо працездатність два тижні після впровадження.

Типові помилки при налаштуванні

  • Shallow clone в CI: відключає аналіз змін — використовуйте fetch-depth: 0.
  • Пропуск виключень для згенерованих файлів: вони завищують кількість запахів.
  • Відсутність coverage report: без нього Quality Gate не перевірить покриття.
  • Занадто м'які пороги: Gate пропускає проблемний код.

Що входить у налаштування SonarQube?

Ми надаємо повний цикл робіт:

  • Розгортання SonarQube (Docker / bare metal / хмара)
  • Налаштування профілів якості та правил під ваш стек
  • Конфігурація Quality Gate з урахуванням ваших вимог
  • Інтеграція з CI/CD (GitHub Actions, GitLab CI, Jenkins, Bitbucket Pipelines)
  • Створення дашбордів та алертів
  • Документація щодо процесу та навчання команди
  • Гарантія коректної роботи протягом двох тижнів після впровадження

Терміни та вартість

Базове налаштування займає від 1 до 2 робочих днів. Складні проекти з кількома репозиторіями та кастомними правилами — до 5 днів. Вартість розраховується індивідуально під кожен проект. Наші інженери впровадили SonarQube на 50+ проектах. Зв'яжіться з нами — ми оцінимо ваш код і запропонуємо оптимальне рішення. Отримайте консультацію прямо зараз.

Чому юніт-тести важливі, але не панацея?

Баг, знайдений юніт-тестом, коштує хвилини виправлення. Той самий баг у продакшені — години інциденту, компенсації та втрата довіри. На проекті інтернет-магазину помилка в розрахунку знижки пройшла ручне тестування, потрапила в прод і за 4 години обробила 37 замовлень за нульовою ціною. Автотест на граничні випадки розрахунку зловив би її при першому ж push. Оцініть свій проект — ми проведемо аудит поточного покриття і дамо рекомендації.

Jest — стандарт для JavaScript/TypeScript, але юніт-тести виправдані тільки там, де є ізольована логіка: функції трансформації, валідатори, бізнес-правила, утиліти. Тестувати React-компоненти через Jest + Testing Library правильно для поведінкових тестів: «кнопка з'являється після завантаження», «форма показує помилку при порожньому email». Снепшот-тести (toMatchSnapshot) — пастка: вони ламаються при будь-якій зміні верстки і стають шумом, який розробники оновлюють не дивлячись. Покриття коду (code coverage) — погана метрика якості: 80% coverage можна отримати тестами, які нічого не перевіряють. Coverage показує, що код виконався, а не те, що він працює правильно.

Критерій Jest Vitest
Швидкість для великих проектів Середня (Babel-трансформація) В 10–20 разів швидше (ES modules)
Інтеграція з Vite Через плагін Нативна
Монорепозиторії Вимагає конфігурації З коробки

Vitest як альтернатива Jest для Vite-проектів: в 10–20 разів швидше завдяки нативним ES modules без трансформації через Babel. Для монорепозиторіїв з тисячами тестів різниця у швидкості відчутна. Детальніше про юніт-тестування.

Як налаштувати E2E тести, які не будуть flaky?

Playwright обійшов Cypress за ключовими параметрами: нативна підтримка multi-tab, multi-origin, iframe; паралельне виконання на рівні тестів; WebKit, Firefox, Chromium з коробки; немає iframe для додатку — тести працюють в реальному браузері.

Playwright codegen записує дії та генерує тест — хороша точка старту, але згенерований код потрібно рефакторити. Локатори за text content крихкі: getByRole('button', { name: 'Оформить заказ' }) — стійкіше, ніж locator('.btn-primary').

Page Object Model — стандарт організації E2E тестів. Кожна сторінка — окремий клас з методами замість прямих локаторів. Коли кнопка переїхала з хедера в сайдбар — міняємо в одному місці, не шукаємо по всіх тестах.

Як уникнути flaky тестів? Типова проблема — flaky tests. Причини: race condition між запитом і рендером, анімації без очікування, залежність від зовнішніх API. Рішення: `page.waitForResponse()` замість `page.waitForTimeout()`, мокування зовнішніх API через `page.route()`.
// Погано
await page.click('#submit');
await page.waitForTimeout(2000);
await expect(page.locator('.success')).toBeVisible();

// Добре
await page.click('#submit');
await page.waitForResponse(resp =>
  resp.url().includes('/api/orders') && resp.status() === 201
);
await expect(page.getByRole('alert', { name: /заказ создан/i })).toBeVisible();

Наші інженери гарантують стабільність тестів у CI. Документація Playwright — основний інструмент на проектах з мільйонами користувачів.

Навантажувальне тестування з k6

k6 — інструмент для навантажувального тестування з JavaScript API. Сценарії пишуться як код, версіонуються в git, запускаються в CI. Три основних сценарії:

  • Spike test — різке зростання навантаження: 0 → 1000 користувачів за 30 секунд. Імітує запуск рекламної кампанії. Показує здатність системи реагувати на піки.
  • Soak test — стабільне навантаження на 2–4 години. Виявляє memory leaks, connection pool exhaustion, деградацію продуктивності.
  • Stress test — навантаження вище розрахункової (150–200% від очікуваного піку). Показує точку відмови та graceful degradation.

Порогові значення:

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

p95 < 500ms означає: 95% запитів відповідають швидше півсекунди. Якщо поріг не виконується — k6 завершується з кодом помилки, CI-пайплайн падає.

На одному проекті інтернет-магазину ми виявили деградацію API на 4-й годині тесту: p95 зріс з 200ms до 2s через витік з'єднань. Після оптимізації клієнт заощадив значну суму на інцидентах та зайвих ресурсах. Отримайте аналогічний аудит вашого проекту — замовте навантажувальне тестування.

Як Core Web Vitals впливають на ранжування?

Google використовує Core Web Vitals у ранжуванні. Lighthouse CLI в CI-пайплайні: при кожному деплої перевіряємо, що LCP < 2.5s, CLS < 0.1, INP < 200ms. Детальніше про веб-продуктивність. Реальні проблеми, які Lighthouse знаходить:

  • Hero image без атрибутів width/height: CLS 0.35 при завантаженні.
  • JavaScript-бандл 2.1MB синхронно блокує парсинг: INP 450ms.
  • Шрифти без font-display: swap: невидимий текст до завантаження шрифту (FOIT).
  • Неоптимізований hero image 4MB: LCP 8.2s.

Lighthouse CI (lhci) зберігає історію метрик і надсилає коментар до PR з деградацією. За даними Google, 53% користувачів залишають сайт при завантаженні довше 3 секунд — наші тести запобігають таким втратам.

Піраміда тестування в проекті

Рівень Інструмент Кількість Швидкість
Юніт Vitest/Jest Багато (тисячі) <5 хв
Інтеграція Vitest + supertest Середня 5–15 хв
E2E Playwright Мало (happy path) 10–30 хв
Навантаження k6 За розкладом 30–60 хв
Продуктивність Lighthouse CI При кожному деплої 5 хв

Що входить в роботу?

  • Аудит поточного покриття та визначення критичних user flows.
  • Написання unit-тестів для ключової бізнес-логіки, інтеграційних тестів для API, E2E для сценаріїв користувача.
  • Налаштування паралельного виконання в CI (sharded workers для Playwright).
  • Навантажувальне тестування зі звітом та рекомендаціями.
  • Документація за тест-кейсами, навчання вашої команди роботі з тестами.
  • Гарантійна підтримка 1 місяць після впровадження.

Процес роботи

  1. Аналітика — аудит поточного тестування, виявлення слабких місць, визначення пріоритетів.
  2. Проектування — вибір інструментів, написання тест-плану, узгодження.
  3. Реалізація — написання тестів, інтеграція в CI.
  4. Тестування — прогін всіх рівнів, аналіз результатів, виправлення помилок.
  5. Деплой — запуск в прод, моніторинг метрик, навчання команди.

Терміни

Налаштування повного тест-пайплайна (Jest + Playwright + k6 + Lighthouse CI) з нуля: 2–4 тижні. Покриття E2E-тестами існуючого проекту (20–30 сценаріїв): 3–6 тижнів. Навантажувальне тестування зі звітом та рекомендаціями: 1–2 тижні. Вартість розраховується індивідуально після аудиту.

Готові обговорити ваш проект? Залиште заявку — ми проведемо аудит поточного тестування безкоштовно і запропонуємо план з економією до 60% часу на інциденти. Отримайте консультацію з тестування веб-додатків — напишіть нам.