Непреривне навантажувальне тестування в CI/CD пайплайні

Неперервне навантажувальне тестування в CI/CD

При кожному деплої в продакшен ризик внести регресію продуктивності — високий. Один неоптимальний SQL-запит або забута N+1 проблема можуть збільшити час відповіді на 50%, і користувач піде до конкурентів. Ми інтегруємо автоматичні навантажувальні тести прямо у ваш CI/CD пайплайн, щоб ловити такі регресії до потрапляння в master. Результат — ви впевнені, що кожен коміт не ламає SLA по latency і throughput.

Налаштуємо smoke-тести з пороговими значеннями, які перетворюють пайплайн на gatekeeper: якщо p95 latency перевищив 500ms або відсоток помилок вище 1% — пайплайн падає, і розробник отримує сповіщення. Це не заміна повноцінному навантажувальному тестуванню, а швидкий запобіжник.

Проблеми, які вирішуємо

• Регресія продуктивності після деплою — навіть мікрозміна в коді може сповільнити критичний endpoint. Без автоматичних тестів ви дізнаєтеся про проблему тільки після скарг користувачів або алертів моніторингу. Ми налаштовуємо baseline-порівняння: кожен тест запускається проти стабільної гілки, і при відхиленні >20% пайплайн блокується.
• Неефективні запити та вузькі місця — наші скрипти емулюють типові користувацькі сценарії (перегляд списку, створення поста, пошук). Якщо запит почав виконуватися довше — ми бачимо це на графіках метрик.
• Відсутність культури performance-first — розробники часто не думають про продуктивність на етапі code review. Continuous Load Testing робить performance видимим: кожен PR супроводжується коментарем з результатами тестів (p95, error rate).

Інструменти та їх місце в CI

k6 — найкращий вибір для CI: JS-скрипти, вбудована статистика, threshold-based pass/fail, нативна інтеграція з GitHub Actions і GitLab CI. Детальніше в k6 documentation.

Artillery — YAML-конфігурація, зручний для опису сценаріїв без коду. Gatling — Scala/Java, детальні HTML-звіти, зручний для Java-команд.

Базовий k6 скрипт

// tests/performance/api-smoke.js
import http from 'k6/http'
import { check, sleep } from 'k6'
import { Rate, Trend } from 'k6/metrics'

// Кастомні метрики
const errorRate = new Rate('errors')
const postCreateDuration = new Trend('post_create_duration')

export const options = {
  // Профіль навантаження для CI: швидко, не руйнівно
  stages: [
    { duration: '30s', target: 10 }, // розігрів
    { duration: '1m', target: 10 }, // стійке навантаження
    { duration: '10s', target: 0 }, // охолодження
  ],
  // Пайплайн зламається якщо поріг не досягнуто
  thresholds: {
    http_req_duration: [
      'p(95)<500', // p95 < 500мс
      'p(99)<1000', // p99 < 1000мс
    ],
    errors: ['rate<0.01'], // помилок < 1%
    http_req_failed: ['rate<0.01'], // HTTP помилок < 1%
    post_create_duration: ['p(95)<800'],
  }
}

const BASE_URL = __ENV.BASE_URL || 'http://localhost:3000'
const AUTH_TOKEN = __ENV.AUTH_TOKEN

export function setup() {
  // Один раз: отримати токен або підготувати дані
  const res = http.post(`${BASE_URL}/api/auth/login`, JSON.stringify({
    email: '[email protected]',
    password: 'testpassword'
  }), {
    headers: { 'Content-Type': 'application/json' }
  })
  return { token: res.json('token') }
}

export default function(data) {
  const headers = {
    'Content-Type': 'application/json',
    'Authorization': `Bearer ${data.token || AUTH_TOKEN}`
  }

  // Сценарій 1: список постів (70% трафіку)
  const postsList = http.get(`${BASE_URL}/api/posts?limit=20`, { headers })
  check(postsList, {
    'posts list: status 200': (r) => r.status === 200,
    'posts list: has items': (r) => r.json('data').length > 0
  })
  errorRate.add(postsList.status !== 200)
  sleep(Math.random() * 0.5) // випадкова пауза 0-500мс

  // Сценарій 2: створення поста (20% трафіку)
  if (Math.random() < 0.2) {
    const start = Date.now()
    const createPost = http.post(`${BASE_URL}/api/posts`, JSON.stringify({
      title: `Test post ${Date.now()}`,
      content: 'Load test content'
    }), { headers })
    postCreateDuration.add(Date.now() - start)
    check(createPost, {
      'create post: status 201': (r) => r.status === 201,
    })
    errorRate.add(createPost.status !== 201)
  }
  sleep(0.3)
}

Як налаштувати пороги продуктивності в k6?

Пороги (thresholds) — ключовий механізм для автоматичного fail пайплайну. В опціях скрипта ми задаємо допустимі межі: наприклад, http_req_duration: ['p(95)<500', 'p(99)<1000']. Це означає, що 95% запитів мають виконуватися швидше 500 мс, а 99% — швидше 1 секунди. Якщо поріг порушено — тест завершується помилкою, і CI зупиняє деплой.

Ми також використовуємо кастомні метрики для конкретних бізнес-операцій (наприклад, час створення поста) і виставляємо окремі пороги на них. Так ви точно знаєте, що критична функціональність не деградує.

GitHub Actions інтеграція

---
# .github/workflows/performance.yml
name: Performance Tests
on:
  push:
    branches: [main, staging]
  pull_request:
    branches: [main]
jobs:
  performance:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:15
        env:
          POSTGRES_DB: testdb
          POSTGRES_PASSWORD: testpass
        ports: ['5432:5432']
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
    steps:
      - uses: actions/checkout@v4
      - name: Start application
        run: |
          docker compose -f docker-compose.test.yml up -d api
          npx wait-on http://localhost:3000/health --timeout 60000
      - name: Run k6 smoke test
        uses: grafana/[email protected]
        with:
          filename: tests/performance/api-smoke.js
          flags: --out json=results.json
        env:
          BASE_URL: http://localhost:3000
          K6_PROMETHEUS_RW_SERVER_URL: ${{ secrets.PROMETHEUS_URL }}
      - name: Parse results
        if: always()
        run: |
          # Показати summary в PR коментарі
          jq -r '.metrics | { p95: .http_req_duration["p(95)"], p99: .http_req_duration["p(99)"], errors: .http_req_failed.rate }' results.json
      - name: Comment PR with results
        if: github.event_name == 'pull_request'
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs')
            const results = JSON.parse(fs.readFileSync('results.json'))
            const p95 = results.metrics.http_req_duration['p(95)'].toFixed(0)
            const errorRate = (results.metrics.http_req_failed.rate * 100).toFixed(2)
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `## Performance Test Results\n\n| Metric | Value | Threshold |\n|--------|-------|-----------|\n| p95 latency | ${p95}ms | <500ms |\n| Error rate | ${errorRate}% | <1% |`
            })
---

Baseline порівняння між деплоями

#!/bin/bash
# scripts/compare-performance.sh
CURRENT_BRANCH=$(git branch --show-current)
BASELINE_BRANCH="main"

# Тест поточного коду
k6 run --out json=current.json tests/performance/api-smoke.js

# Переключитися на baseline
git stash
git checkout $BASELINE_BRANCH
docker compose up -d --build api
sleep 10
k6 run --out json=baseline.json tests/performance/api-smoke.js

# Порівняння
node - <<'EOF'
const current = require('./current.json')
const baseline = require('./baseline.json')
const metrics = ['http_req_duration']
for (const m of metrics) {
  const cp95 = current.metrics[m]['p(95)']
  const bp95 = baseline.metrics[m]['p(95)']
  const delta = ((cp95 - bp95) / bp95 * 100).toFixed(1)
  if (cp95 > bp95 * 1.2) {
    // регресія > 20%
    console.error(`REGRESSION: ${m} p95 degraded by ${delta}%`)
    process.exit(1)
  }
  console.log(`${m} p95: ${cp95}ms vs ${bp95}ms baseline (${delta}%)`)
}
EOF

# Повернутися на поточну гілку
git checkout $CURRENT_BRANCH
git stash pop

Artillery для опису сценаріїв

---
# tests/performance/user-journey.yml config:
target: "{{ $processEnvironment.BASE_URL }}"
phases:
  - duration: 60
    arrivalRate: 5
    rampTo: 20
    name: "Ramp up"
  - duration: 120
    arrivalRate: 20
    name: "Sustained load"
ensure:
  thresholds:
    - http.response_time.p95: 500
    - http.request_rate: 15
scenarios:
  - name: "Browse and purchase"
    weight: 70
    flow:
      - get:
          url: "/api/products"
          expect:
            - statusCode: 200
      - post:
          url: "/api/cart"
          json:
            productId: "{{ $randomInt(1, 100) }}"
            quantity: 1
  - name: "Search only"
    weight: 30
    flow:
      - get:
          url: "/api/search?q={{ $randomString(5) }}"

Порівняння інструментів навантажувального тестування

Чому варто використовувати k6 для CI?

k6 має вбудовану підтримку CI/CD: він працює як CLI-утиліта, не потребує графічного інтерфейсу, а результати можна виводити в JSON для подальшої обробки. На відміну від Gatling (вимагає Scala/Java та генерації HTML-звітів) або Artillery (YAML-конфіги, але менше метрик), k6 надає гнучкі метрики та просту інтеграцію з GitHub Actions через готові action. Для команд, які вже використовують JavaScript, поріг входу мінімальний.

Процес роботи

1. Аналітика — визначаємо критичні ендпоінти та користувацькі сценарії.
2. Проектування — розробляємо навантажувальні сценарії, налаштовуємо профілі навантаження (ramp-up, sustained).
3. Реалізація — пишемо скрипти (k6, Artillery або Gatling), інтегруємо їх в CI.
4. Тестування — запускаємо smoke-тести на staging, коригуємо thresholds.
5. Деплой — включаємо тести в пайплайн, налаштовуємо автоматичні коментарі в PR.

Строки та що входить

Налаштування базового набору k6 smoke-тестів з порогами та інтеграцією в CI займає від 1 до 2 робочих днів. Якщо потрібне порівняння з baseline та кастомні метрики — розширюємо до 3-5 днів. До складу робіт входить:

• Скрипти навантажувальних тестів (2-3 сценарії)
• Конфігурація thresholds
• Інтеграція з GitHub Actions або GitLab CI (YAML pipeline)
• PR-коментар з результатами тестів
• Документація по запуску та підтримці
• Консультація команди щодо інтерпретації результатів

Ми гарантуємо, що тести не заважатимуть основному процесу розробки: вони запускаються паралельно і займають не більше 5 хвилин.

Чому обирають нас

• Більше 5 років досвіду в навантажувальному тестуванні та CI/CD
• 50+ успішних проектів — від стартапів до enterprise
• Використовуємо тільки перевірені інструменти (k6, Grafana, Prometheus)
• Надаємо гарантію на коректну роботу тестів протягом місяця після впровадження

Зв'яжіться з нами, щоб обговорити ваш проект: отримайте консультацію з інтеграції Continuous Load Testing у ваш пайплайн.