Ответ
В 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 и должны пройти успешно, чтобы код попал в стадию сборки или деплоя.
Ответ 18+ 🔞
А, ну это же классика! Сидишь такой, настраиваешь очередной пайплайн, а в голове одна мысль: "Чтоб ничего не проскочило, а то потом овердохуища проблем будет". Давай по пунктам, как я это обычно делаю, чтобы потом не охуеть от последствий.
Первое дело — статический анализ. Это как зубной врач для кода: неприятно, но необходимо. Ставлю ESLint с airbnb-base, чтобы код не выглядел, как будто его пьяный мартышлюшка набирал. Особенно гоняю по двум правилам: сложность функций (complexity) и количество строк в них. Если функция на три экрана — это уже не функция, а манда с ушами, её надо резать. Плюс TypeScript в строгом режиме — без него чувствуешь себя голым, доверия к коду — ноль ебать. И конечно, SonarQube сверху, чтобы следить за долгом и дублями. Если дублирования больше 3% — это уже не код, а копипаста какая-то, сразу фейл.
Дальше — тестирование. Тут без компромиссов. Покрытие — минимум 80%, и особенно смотрю на покрытие веток (branches). Если if или switch не покрыты — это как ходить по охуенно тонкому льду, рано или поздно провалишься. В package.json прописываю пороги жёстко, чтобы jest сразу ругался.
"scripts": {
"test:coverage": "jest --coverage --coverageThreshold='{"global":{"branches":80,"functions":80,"lines":80,"statements":80}}'"
}И гоняю всё: unit-тесты, интеграционные (с отдельной тестовой базой, чтобы не засирать прод), и API-тесты через Supertest. Если что-то падает — всё, приехали, дальше не пускаю.
Третий пункт — зависимости. npm audit — наш страж. Находит какую-нибудь уязвимость с CVSS 9.5, и я такой: "Ни хуя себе, мы же с этой либой в проде живём!". Критические уязвимости — стоп-кран для пайплайна. А чтобы не отставать, ставлю Renovate или Dependabot. Пусть сами обновления присылают, только мерж-реквесты апрувь.
Ревью кода — это святое. Два апрува минимум. И смотрю не только "работает/не работает", а чтобы код был читаемый, без нарушений SOLID и DRY. Если вижу функцию на 200 строк, которая делает всё — от запроса в базу до отправки письма, — это пизда рулю. Отправляю на переделку. Распиздяйство не прокатит.
Безопасность. Тут вообще расслабляться нельзя. Обязательно сканирую репу на предмет случайно закоммиченных секретов (типа паролей или API-ключей). Один раз чувак токен от AWS в конфиг засунул и залил — ебать колотить, хорошо, что сканер отловил. И все Docker-образы прогоняю через Trivy — искать дыры.
Ну и напоследок, производительность. Для веб-сервисов — нагрузочное тестирование, чтобы проверить, не начнёт ли он память жрать как не в себя под нагрузкой. А если это npm-библиотека — лимит на размер бандла. Чтобы пользователь не качал ради одной функции библиотеку на 50 мегабайт, это же пидарас шерстяной.
Всё это дело встраиваю в GitHub Actions или GitLab CI. И пока все эти гейты не станут зелёными — ни о какой сборке или, тем более, деплое речи быть не может. Сурово, зато потом спать спокойно можно.
