Автоматичний запуск тестів при Pull Request: CI/CD пайплайн

Автоматичний запуск тестів при Pull Request

Уявіть: ви щойно змержили PR у main, а за хвилину прод впав з помилкою. Виявилося, новий модуль затер старий endpoint, і жоден тест цього не помітив. Така ситуація знайома багатьом командам. Ми через це пройшли і відтоді впровадили залізне правило: кожен PR проходить через автоматичний пайплайн тестів. Без зеленого світла — мерж заборонено. Автозапуск тестів при PR — базовий захист від регресій. Розробник не може змержити код, який ламає існуючу функціональність. Це не заміна code review, а його доповнення: рев'юер фокусується на логіці, а не на ловлі очевидних багів.

Згідно з документацією GitHub Actions, кешування залежностей скорочує час встановлення з 90 секунд до 5 секунд — у 18 разів швидше. А матричний запуск тестів дозволяє перевірити різні версії оточення паралельно, прискорюючи загальний прогін у 3–4 рази. Завдяки цьому економиться до 40 годин на місяць на налагодженні, що при середніх ставках дає значну економію. Наш досвід — понад 5 років у CI/CD та 100+ налаштованих пайплайнів — підтверджує: автозапуск тестів окупається за перший же спринт.

Чому автозапуск тестів при PR критичний?

Без цього захисту ви ризикуєте:

• Зламаним CI на main — якщо влили баг, весь наступний спринт піде на фікс.
• Втратою часу на code review — рев'юери відволікаються на помилки, які могли б відловити тести.
• Ручним тестуванням — чим менше рутини, тим вища швидкість постачання.

Які тести варто запускати, а які — ні?

Структура пайплайну

Грамотний пайплайн розбитий на паралельні джоби зі стратегією fail-fast:

# .github/workflows/pr.yml name: PR Tests on: pull_request: branches: [main, develop] concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true # Відміняємо старі запуски при новому push jobs: lint: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: { node-version: 20, cache: npm } - run: npm ci - run: npm run lint && npm run type-check unit: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: { node-version: 20, cache: npm } - run: npm ci - run: npm test -- --coverage - uses: codecov/codecov-action@v4 with: token: ${{ secrets.CODECOV_TOKEN }} integration: runs-on: ubuntu-latest services: postgres: image: postgres:16 env: POSTGRES_DB: testdb POSTGRES_PASSWORD: test options: >- --health-cmd pg_isready --health-interval 5s --health-timeout 5s --health-retries 5 steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: { node-version: 20, cache: npm } - run: npm ci - run: npm run test:integration env: DATABASE_URL: postgresql://postgres:test@localhost:5432/testdb 

Як налаштувати кешування для прискорення пайплайну?

Без кеша npm ci на холодному раннері — 60–90 секунд. З кешем — 5–10 секунд. Використовуйте вбудований кеш actions/setup-node або явний через actions/cache:

# Кеш node_modules по package-lock.json - uses: actions/setup-node@v4 with: node-version: 20 cache: npm # Вбудований кеш в actions/setup-node # Або явно через actions/cache - uses: actions/cache@v4 with: path: ~/.npm key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} 

Вплив кешування на швидкість:

Матричне тестування та підтримка різних стеків

Якщо застосунок має працювати на кількох версіях Node.js або PHP, використовуйте матрицю:

strategy: matrix: node-version: [18, 20, 22] fail-fast: false # Запускаємо всі версії навіть якщо одна впала 

Для Laravel-проєктів використовуйте паралельний запуск PHPUnit:

- name: Run PHPUnit run: php artisan test --parallel --coverage-clover=coverage.xml env: DB_CONNECTION: pgsql DB_DATABASE: testing - name: Upload coverage uses: codecov/codecov-action@v4 with: files: coverage.xml 

--parallel запускає тести паралельно через brianium/paratest. На 200+ тестах прискорює в 3–4 рази.

Статус-чеки та branch protection

У GitHub Settings → Branches → Branch protection rules додаємо required status checks: lint, unit, integration. Мерж в main без проходження цих перевірок неможливий.

Оптимізація швидкості: path filtering та test splitting

• Path filtering — запускати тести тільки при зміні релевантних файлів (наприклад, через paths у GitHub Actions).
• Test splitting — розподілити тести по кількох раннерах (GitHub Actions matrix).
• Тільки змінені модулі — Jest --changedSince, pytest --testpaths.

Мета: пайплайн вкладається в 5 хвилин. Повільніше — розробники починають ігнорувати.

Процес налаштування та що входить у роботу

1. Аналізуємо поточні тести та інфраструктуру проєкту.
2. Проєктуємо пайплайн: визначаємо джоби, матриці, кеш.
3. Реалізуємо конфігурацію GitHub Actions з урахуванням вашого стеку.
4. Налаштовуємо branch protection та обов'язкові статус-чеки.
5. Тестуємо на реальному PR, налагоджуємо.
6. Документуємо процес і передаємо команді.

У результаті ви отримуєте:

• Конфігурацію GitHub Actions з кешуванням та матрицею
• Статус-чеки та правила branch protection
• Coverage-репорти (Codecov, Coveralls)
• Документацію щодо запуску тестів локально
• Доступ до нашого шаблону швидкого старту для нових проєктів
• Пост-релізну підтримку протягом двох тижнів

Строки та вартість

Базова настройка з unit та integration тестами для Node.js або PHP займає 1–2 дні. Налаштування coverage та badge — ще півдня. Підсумкові строки залежать від складності проєкту (кількість сервісів, типи тестів). Вартість обговорюється індивідуально.

Замовте налаштування CI-пайплайну у наших інженерів — ми гарантуємо стабільний пайплайн та документацію. Отримайте консультацію щодо впровадження — зв'яжіться з нами, щоб обговорити ваш проєкт.