Ответ
В CI/CD пайплайне Node.js-проектов я настраиваю следующие обязательные Quality Gates:
-
Статический анализ кода:
- ESLint с конфигурацией
eslint-config-airbnb-baseилиstandard. Критически важные правила:complexity(максимальная цикломатическая сложность 10-15) иmax-lines-per-function. - TypeScript (если используется) с strict-режимом.
- SonarQube/SonarCloud для метрик: поддержания долга, дублирования кода (>3% — fail), надежности и безопасности.
- ESLint с конфигурацией
-
Тестирование:
- Покрытие кода (Code Coverage): Минимум 80% для unit-тестов (Jest). Бранчи (
branches) — самый важный критерий.// package.json "scripts": { "test:coverage": "jest --coverage --coverageThreshold='{"global":{"branches":80,"functions":80,"lines":80,"statements":80}}'" } - Обязательный прогон unit, интеграционных (с тестовой БД) и API-тестов (с использованием Supertest).
- Покрытие кода (Code Coverage): Минимум 80% для unit-тестов (Jest). Бранчи (
-
Анализ зависимостей:
npm audit/yarn audit— блокировка пайплайна при обнаружении критических уязвимостей (CVSS >= 9).- Renovate или Dependabot для автоматического обновления зависимостей с созданием MR.
-
Code Review: Обязательный процесс Pull Request с 2 апрувами, проверкой на соответствие принципам SOLID/DRY и читаемости кода.
-
Безопасность:
- Сканирование секретов в коде (например, с помощью
truffleHogили GitGuardian). - Проверка Docker-образов на уязвимости (Trivy, Grype).
- Сканирование секретов в коде (например, с помощью
-
Производительность и размер (для приложений):
- Для сервисов — проверка на утечки памяти с помощью нагрузочного тестирования (Artillery, k6).
- Для пакетов (npm-библиотек) — лимит на размер бандла (например, с помощью
size-limit).
Эти гейты интегрируются в пайплайн GitHub Actions/GitLab CI и должны пройти успешно, чтобы код попал в стадию сборки или деплоя.