Ответ
В проекте использовался GitHub, и для основной ветки (main) были настроены строгие правила (branch protection rules), которые требовали прохождения всех обязательных проверок перед мержем PR.
Основные проверки включали:
- Статический анализ кода (Linting): Запуск
ESLintдля JavaScript/TypeScript кода. PR не мог быть смержен, если линтер находил ошибки. - Запуск юнит-тестов: Пакет
jestзапускал все юнит-тесты. Падение любого теста блокировало мерж. - Проверка покрытия кода (Code Coverage): Инструмент
istanbul/nycвычислял покрытие для измененных файлов. Мы требовали минимум 80% покрытия для новых строк кода. - Интеграционные/E2E тесты: Наш CI-пайплайн в GitHub Actions запускал набор критических E2E-тестов на
Cypressв headless-режиме. - Сборка проекта: Успешная сборка проекта (
npm run build) была обязательным условием. - Ревью кода: Требовалось минимум одно одобрение (approve) от другого разработчика и одно одобрение от QA-инженера. Я, как QA, проверял не только функциональность, но и наличие/адекватность тестов для изменений.
Конфигурация в .github/workflows/pr-checks.yml выглядела так:
name: PR Checks
on: [pull_request]
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install dependencies
run: npm ci
- name: Run linter
run: npm run lint
- name: Run unit tests with coverage
run: npm run test:coverage
- name: Build project
run: npm run build
- name: Run E2E tests
run: npm run test:e2e:ci