Belajar Performance Test Engineer - Performance in CI/CD

#Pendahuluan

Setelah di episode 13 kita memahami distributed load testing, kini saatnya mengintegrasikan performance testing ke dalam CI/CD pipeline — langkah krusial dalam shift-left performance engineering. Tanpa CI/CD integration, performance regression bisa lolos ke production tanpa seorang pun sadari sampai user mengeluh.

Performance gates di CI/CD memastikan setiap code change tidak memperburuk performa. Jika commit baru menyebabkan latency naik 50%, pipeline harus gagal sebelum code merged ke main. Ini mengubah performance testing dari aktivitas batch sebelum release menjadi bagian dari daily workflow.

#Performance Gates

#Apa itu Performance Gate

Performance gate adalah aturan dalam CI/CD pipeline yang memvalidasi apakah code change memenuhi target performa. Jika test gagal, pipeline dihentikan — developer harus memperbaiki sebelum code bisa di-merge.

#Threshold-Based Gates

# GitHub Actions: performance gate
- name: Run Performance Test
  run: |
    k6 run --vus 50 --duration 2m \
      --threshold "http_req_duration{p(95)<500}" \
      --threshold "http_req_failed<0.01" \
      scripts/load-test.js
 
- name: Check Results
  if: failure()
  run: echo "Performance gate failed — p95 latency exceeded 500ms"

#Baseline Comparison

Threshold tetap kaku — bisa gagal karena fluktuasi environment. Pendekatan lebih baik: bandingkan dengan baseline dari commit sebelumnya.

# Jalankan test dan simpan hasil
k6 run --out json=results.json scripts/load-test.js
 
# Bandingkan dengan baseline
python scripts/compare-results.py --baseline baseline.json --current results.json --tolerance 10

#Regression Detection

#Apa itu Performance Regression

Performance regression adalah penurunan performa yang disebabkan oleh code change — latency naik, throughput turun, atau error rate meningkat. Regression bisa bersifat gradual (bertambah lambat per commit) atau sudden (satu commit menyebabkan masalah besar).

#Automated Regression Detection

# Script perbandingan hasil test
import json
 
def compare_results(baseline, current, tolerance=10):
    base_p95 = baseline['metrics']['http_req_duration']['p(95)']
    curr_p95 = current['metrics']['http_req_duration']['p(95)']
    change_pct = ((curr_p95 - base_p95) / base_p95) * 100
 
    if change_pct > tolerance:
        print(f"REGRESSION DETECTED: p95 latency naik {change_pct:.1f}%")
        return False
    print(f"OK: p95 latency berubah {change_pct:.1f}% (dalam toleransi)")
    return True

#Statistical Significance

Jangan langsung panik jika hasil test berbeda 5% dari baseline — ada noise dalam testing. Gunakan statistical significance untuk membedakan noise dari regression nyata:

• Jalankan test minimal 3 kali
• Hitung rata-rata dan standard deviation
• Gunakan t-test untuk membandingkan baseline dengan current
• Hanya flag regression jika perbedaan statistically significant (p-value 0.05)

#CI/CD Integration Patterns

#GitHub Actions

name: Performance Test
on:
  pull_request:
    paths:
      - 'src/**'
 
jobs:
  perf-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Install k6
        run: |
          sudo gpg -k
          sudo gpg --no-default-keyring --keyring /usr/share/keyrings/grafana.gpg \
            --keyserver keyserver.ubuntu.com --recv-keys 379CE192D401AB61
          echo "deb [signed-by=/usr/share/keyrings/grafana.gpg] https://packages.grafana.com/oss/deb stable main" | \
            sudo tee /etc/apt/sources.list.d/grafana.list
          sudo apt-get update && sudo apt-get install -y k6
 
      - name: Run load test
        run: k6 run --vus 20 --duration 1m scripts/load-test.js
 
      - name: Upload results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: perf-results
          path: results/

#Performance Budget

Performance budget adalah batas atas untuk metrik performa yang tidak boleh dilanggar:

// k6 script dengan performance budget
export const options = {
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1000'],
    http_req_failed: ['rate<0.01'],
    http_reqs: ['rate>100'],  // Minimal 100 RPS
  },
};

#Menangani False Positives

#Fluktuasi Environment

CI/CD runners punya performance yang bervariasi — kadang lebih lambat karena concurrent jobs lain. Strategi:

• Increase tolerance: 10-15% toleransi untuk fluktuasi
• Run multiple times: 3x execution, ambil median
• Dedicated runners: gunakan runners khusus untuk performance test

#Environmental Factors

External factors bisa mempengaruhi test: network latency ke target, DNS resolution, CDN cache. Untuk konsistensi:

• Gunakan staging environment yang terisolasi
• Mock external services jika mungkin
• Fix seed data agar test deterministik

#Monitoring Performance Over Time

#Trend Dashboard

Buat dashboard Grafana yang menampilkan tren performa dari waktu ke waktu — setiap commit yang mengubah baseline akan terlihat di grafik.

# Tren p95 latency dari waktu ke waktu
avg_over_time(http_request_duration_seconds{quantile="0.95"}[1h])

#Alerting

Set up alerting untuk regression yang terdeteksi otomatis:

# Prometheus alerting rule
groups:
  - name: performance
    rules:
      - alert: PerformanceRegression
        expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 0.5
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Performance regression detected: p95 latency above 500ms"

#Penutup

Di episode 14 ini kalian telah memahami performance in CI/CD:

• Performance gates: threshold-based dan baseline comparison.
• Regression detection: automated detection dengan statistical significance.
• CI/CD patterns: GitHub Actions integration, performance budgets.
• False positives: tolerance, multiple execution, dedicated runners.
• Monitoring over time: trend dashboard dan alerting.

Di episode 15 selanjutnya, kita akan membahas Caching & CDN Testing — bagaimana menguji cache hit ratio, CDN performance, dan dampak caching terhadap performa sistem. Siapkan Redis kalian!