Настройка 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 из-за утечки соединений. После оптимизации клиент сэкономил около $15,000 в год на инцидентах и лишних ресурсах. Получите аналогичный аудит вашего проекта — закажите нагрузочное тестирование.

Как 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 мин
Performance 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% времени на инциденты. Получите консультацию по тестированию веб-приложений — напишите нам.