CI/CD'de performans testi: pipeline'da yük testi kapısı

Algebran Yazılım & Danışmanlık · Yayın 5 Ekim 2026

Performans gerilemeleri genellikle tek bir büyük değişiklikle değil, birçok küçük değişikliğin birikmesiyle gelir: bir sorguya eklenen bir JOIN, kaldırılan bir önbellek, büyüyen bir JSON yanıtı. Sürümden önce bir kez yapılan yük testi bunları geç yakalar; hangi değişikliğin sebep olduğunu bulmak da zorlaşır. Performans testini CI/CD pipeline'ına almak gerilemeyi değişiklikle aynı gün görmenizi sağlar.

Pipeline'ın neresinde, ne kadar?

Her commit'te bir saatlik soak testi koşturmak ne mümkün ne de gerekli. İşe yarayan düzen genellikle üç katmanlıdır:

• Her pull request'te: staging ya da geçici bir ortama karşı 3–10 dakikalık kısa bir yük testi, beklenen yükte ya da onun bir kesrinde. Amaç kapasiteyi ölçmek değil, belirgin gerilemeyi yakalamaktır: adım bazında p95 ve hata oranı, eşikler ve bir referans koşuyla karşılaştırma.
• Her gece: daha uzun ve daha gerçekçi bir yük testi; tam veri seti, birden çok senaryo, gerekirse birden çok lokasyon. Sonuç sabah ekibin kanalında olur.
• Sürüm öncesi: kırılma noktası testi, spike ve gerekiyorsa soak (test türleri). Bunlar genellikle pipeline'ı bloklamaz, karar toplantısına girdi olur.

Gürültüyle başa çıkmak

CI'daki performans testinin en büyük düşmanı gürültüdür: aynı kod iki koşuda %5–10 farklı sonuç verebilir. Kapı her gün sebepsiz kırılırsa ekip ona güvenmeyi bırakır. Gürültüyü azaltmak için:

• Testi paylaşılan, başka yük alan bir ortama değil, mümkünse ayrılmış ve sabit boyutlu bir ortama karşı koşturun.
• Her koşuda aynı veriyle başlayın; önbelleklerin ısınması için kısa bir ramp-up bırakın.
• Mutlak eşikleri gerçekçi ve biraz gevşek tutun (örneğin p95 hedefinin %20 üstü); küçük kaymaları referans koşuyla karşılaştırma ve toleransla yakalayın.
• Kritik adımlara ayrı eşik koyun; genel p95 tek başına adımdaki gerilemeyi gizler (p95 ve p99 rehberi).

Güvenlik ve yetki

Pipeline'a verilen kimlik bilgisi yalnız gerekeni yapabilmelidir. Yük testi aracının yönetici parolası değil, test koşturmakla sınırlı ve iptal edilebilir bir token kullanın; token'ı pipeline secret'ı olarak saklayın. Veri değiştiren testleri PR pipeline'ından canlı ortama karşı koşturmayın.

Spitfire ile

Testi Spitfire'da bir kez kaydedersiniz; pipeline onu controller'da adıyla koşturur. Profil menüsünden API token'ları'nda kişisel bir token oluşturun ve pipeline secret'ı olarak SPITFIRE_TOKEN adıyla saklayın. Token kullanıcısının güncel rolü ve gruplarıyla çalışır ve yalnız koşuları okuyabilir, doğrulayabilir, başlatıp durdurabilir. Başlattığı koşular ci etiketi ve pipeline bilgisiyle işaretlenir, token'ın adıyla denetim kaydına yazılır.

# .github/workflows/load-test.yml
on: [pull_request]
permissions:
  contents: read
  pull-requests: write          # the PR comment
jobs:
  load-test:
    runs-on: ubuntu-latest
    steps:
      - env:
          SPITFIRE_URL: https://spitfire.example.com
          SPITFIRE_TOKEN: ${{ secrets.SPITFIRE_TOKEN }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          curl -fsSL "$SPITFIRE_URL/api/v1/runner-dist/spitfire-cli-linux-amd64.gz" | gunzip > spitfire && chmod +x spitfire
          ./spitfire cloud run "Checkout flow" --env staging --pr-comment --summary-md spitfire.md

spitfire cloud run koşuyu bekler ve sonucu çıkış koduyla bildirir; pipeline adımı buna göre geçer ya da kalır:

Karşılaştırmalı koşu (--compare A=test,B=dev) kararıyla çıkar: daha iyi ya da fark yoksa 0, daha kötüyse 98, geçersizse 97, B kolunun eşikleri kırıldıysa 99. Ayrıntı: sürüm karşılaştırma.

Sık kullanılan seçenekler: --env staging testi ortamlarından birine karşı koşturur, --scale 0.5 yükü yarıya indirir, --var anahtar=değer bir değişkeni o koşu için değiştirir, -l istanbul=60:2 -l frankfurt=40 koşuyu lokasyonlara böler, -o summary.json özeti, --report report.pdf raporu build artifact'ı olarak saklar. CLI ayrıca imajın içinde de gelir: docker run --rm -e SPITFIRE_URL -e SPITFIRE_TOKEN algebransoft/spitfire spitfire cloud run …

Gece koşuları pipeline'sız da olur

Gece katmanı için pipeline şart değildir: test sayfasında Zamanla ile testi her gece ya da hafta içi her sabah koşturursunuz. Eşik kırılınca, koşu hata verince ya da zamanlanmış koşu başlamayınca Slack, Teams, SMS ya da e-postayla haber gelir. Koşu referans koşusundan belirgin biçimde kötüyse (p95, p99, hata oranı, istek/sn) eşik kırılmadan da uyarı gider; böylece yavaş yavaş biriken gerileme, kullanıcı fark etmeden görünür.

Pull request'te performans farkı

--pr-comment pull request'e (GitHub Actions) ya da merge request'e (GitLab CI) bir özet yazar: her adımın p95, p99 ve hata oranı, testin referans koşusuyla karşılaştırmalı; toleransı aşan kötüleşmede ⚠️. Her push aynı yorumu günceller. --summary-md aynı Markdown'ı dosyaya yazar; GitHub'da iş sayfasına da gider. Test sayfasında adım başına performans bütçesi (örneğin POST /orders p95 < 300 ms) tanımlanır; aşılan bütçe koşuyu eşik gibi kaldırır (çıkış kodu 99). Test sayfası son koşuların adım p95 trendini sürüm etiketi ya da commit ile gösterir. Yalnız CI işi GitHub ya da GitLab ile konuşur; controller hiç konuşmaz.

CI'da eşiğe göre geçti/kaldı ve bütün protokoller ücretsiz sürümde de açık. PR yorumları ve performans bütçeleri şu planlarda: Growth yıllık, Scale yıllık, Enterprise yıllık. GitLab örneği ve diğer ayrıntılar: kurulum rehberi, CI/CD.