Core/Dash CI/CD otomatik performans kontrolleri

Hangi deploy yavaşlattı?

LCP'n iki ay önce 2,1 saniyeydi. Şimdi 2,9 saniye. O zamandan beri kırk kez deploy çıktın, sadece zaman çizelgesine bakarak bunu hangi deploy'un yaptığını bulamazsın.

Bu yüzden Core/Dash her gerçek kullanıcının her ziyaretini belirli bir deploy ile eşleştirir. Regresyon "geçen ay bir şeyler yavaşladı" yerine "bunu v2.4.1 yaptı" haline gelir.

Core/Dash her deploy'un etrafında iki kontrol çalıştırır. Yayına girmeden önce, Core/Dash önizleme build'ini tarar ve bir sayfa bütçeyi aşarsa pipeline'ı işaretler. Yayına girdikten sonra, her sayfa görüntülemesi onu sunan sürümle etiketlenir, böylece her sürüm kendi gerçek kullanıcı trafiğine karşı ölçülür.

İki kontrol farklı hataları yakalar. Deploy öncesi kontrol sentetiktir, bu yüzden build'in kendisinde yaşayan hataları görür: 4MB'lık PNG olan yeni hero görseli, bundle'a 300KB script ekleyen pazarlama etiketi. Bir sürümün LCP, INP ve CLS'e gerçekte ne yaptığı sadece field data'da ortaya çıkar, çünkü Iowa'daki bir veri merkezi gerçek kullanıcılarının New York'taki 4G bağlantılı Android telefonu değildir.

Deploy'dan önce: önizlemeyi kontrol et

Core/Dash puanlayabileceği bir Lighthouse bütçesi taşıyan izlenen ilk dört sayfayı kontrol eder ve her birini production yerine önizleme ortamına karşı çalıştırır. Bu, kendi Core/Dash performans bütçelerinle karşılaştırılır. Bir sayfa sınırı aşarsa, deploy çıkmadan önce bildirim alırsın. Bu bildirimle ne yapacağın sana kalmış.

Bu kontrolü dürüst tutmak için Core/Dash yalnızca aynı build'in iki çalışması arasında değişmeyen şeyleri puanlar. Bir Lighthouse performans puanı tamamen aynı sayfanın iki çalışması arasında on puan oynayabilir, çünkü CPU zamanlamalarının etkisindedir ve denetimi çalıştıran makine hiçbir zaman iki kez aynı olmaz. Bunu CI'da puanlarsan hiçbir anlam ifade etmeyen kırmızı pipeline'lar elde edersin.

Kontrolü CI/CD pipeline'ına ekle

Önce bir proje API anahtarı oluştur (uygulamada: projen, sonra AI Insights, sonra Connect Your AI). Ardından deploy görevinden önce bu adımı ekle. Bu adım kontrol uç noktasını çağırır ve yaklaşık 30 ila 45 saniye sürer.

STATUS=$(curl -sS -o gate.json -w '%{http_code}' -X POST "https://app.coredash.app/api/project/releases/check" \
  -H "Authorization: Bearer $COREDASH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tag":"v1.2.3","origin":"https://preview.example.app"}')

if [ "$STATUS" != "200" ]; then
  echo "CoreDash check failed to run (HTTP $STATUS): $(cat gate.json)" >&2
  exit 0
fi

VERDICT=$(jq -r '.data.check.status' gate.json)
echo "CoreDash: $VERDICT"

# if [ "$VERDICT" = "breach" ]; then exit 1; fi   ## deploy'u engellemek için yorumu kaldır

Varsayılan olarak bu, kararı yalnızca CI loglarına raporlar. Bir sayfa bütçeyi aştığında build'i başarısız yapmak için son satırın yorumunu kaldır.

Değişkenler:

Git alanları uygulamadaki derin bağlantılar için saklanır, hiçbir mantık bunlara bağlı çalışmaz.

Dönüş değerleri:

Geçerli bir istek her zaman HTTP 200 yanıtı verir. Karar data.check.status adresinde bulunur:

Kontrol sayfa bazında fail-open çalışır. PageSpeed Insights dördünden birinde timeout'a düşerse, o sayfa bir hata girdisi olarak geri döner ve diğer üçü yine de puanlanır, böylece Google'daki kötü bir dakika sürümünü engellemez. Bu tasarımdan iki şey çıkar. Önizleme genel internetten erişilebilir olmalıdır, çünkü Google onu getirir (şifre korumalı bir önizleme taranamaz, bu yüzden kontrolü bunun yerine herkese açık bir staging origin'ine yönlendir). Ve önizleme numaraları asla production bütçe panona düşmez.

Deploy'dan sonra: sürümü kaydet

curl -sS -X POST "https://app.coredash.app/api/project/releases/ingest" \
  -H "Authorization: Bearer $COREDASH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tag":"v1.2.3"}'

GitHub Actions'ta, sürüm olarak git ref ile:

- name: Report release to CoreDash
  if: success()
  env:
    COREDASH_API_KEY: ${{ secrets.COREDASH_API_KEY }}
  run: |
    curl -sS -f -X POST "https://app.coredash.app/api/project/releases/ingest" \
      -H "Authorization: Bearer ${COREDASH_API_KEY}" \
      -H "Content-Type: application/json" \
      -d "{\"tag\":\"${{ github.ref_name }}\"}"

curl çalıştırabilen her CI iş görür. GitLab, Jenkins, CircleCI, bir yerlerdeki bir sunucudaki bash deploy betiği. Kontrole gönderdiğin aynı tag değerini gönder, çünkü tarama sonucunu ve gerçek kullanıcı metriklerini tek bir sürümde birleştiren şey budur.

deployedAt isteğe bağlıdır ve varsayılanı şu andır. Zaten çıktığın bir deploy'u geçmişe dönük kaydetmek için bunu geçmiş bir zamana ayarla. notes 2000 karaktere kadar alır ve kontroldeki git alanları burada da çalışır. Bir sürüm proje ve etiket başına benzersizdir, bu yüzden bir etiketi yeniden göndermek ikinci bir satır oluşturmak yerine o satırı günceller ve bir rollback ait olduğu sürüme dahil olur.

Pipeline'ın yok mu? Releases sayfasında bir Tag deployment formu var. Bu daha zayıf bir seçenektir ve bu konuda dürüst olmak gerek, çünkü yalnızca birinin girmeyi hatırladığı deploy'ları, hatırladıkları zamanda kaydeder.

Trafik nasıl ilişkilendirilir

Bir sürümü kaydetmek, onu projeye mevcut sürüm olarak damgalar. İzleme betiğini sunan host bu damgayı okur ve etiketi snippet'e enjekte eder, böylece o andan itibaren her sayfa görüntülemesi sürümü rel boyutunda taşır. Edge kopyası damga değiştiği anda Cloudflare'den temizlenir, bu yüzden bir CDN cache'ini beklemezsin. Eğer uygulaman kendi build ID'sini biliyor ve CI'ın bilmiyorsa, tracker yüklenmeden önce window.__CWVREL değerini ayarla ve o geçerli olur (bunu gerçek bir sürüm dizgisi olarak tut, çünkü istek başına değişen bir build hash'i sana her sayfa görüntülemesinde yeni bir boyut değeri verir ve çalıştırdığın her gruplandırılmış sorguyu bozar).

Metrikler sürümlerini yalnızca bu etiket üzerinden bulur, başka hiçbir şeye bakmaz. Core/Dash'in iki zaman damgası arasındaki trafiğin muhtemelen bir sürüme ait olduğunu tahmin ettiği bir time-window fallback'i yoktur. Etiketlenmemiş trafiği olan bir sürüm tire gösterir, ki bu önceki sürümün kullanıcılarını sessizce yeni sürümüne yazan bir sayıdan daha iyidir. Bir karar beklemeden önce ona 200 civarında sayfa görüntülemesi ver. Bunun altında bir pass veya fail sadece gürültüdür.

Bu kararlar zaten alerts and notifications tarafında çalıştırdığın RUM bütçelerinden gelir. Yapılandırılacak ikinci bir eşik seti yoktur.

Sürüm durumları

Yalnızca released projeyi damgalar ve trafiğini etiketler. Deploy edilmeyen sürümler "Blocked" veya "Awaiting deploy" etiketiyle zaman çizelgesinde görünmeye devam eder ve bloke edilmiş bir satır sınırı aşan metrikleri taşır, böylece bir hafta sonra o sürümün neden hiç yayına çıkmadığını hâlâ görebilirsin.

Core/Dash'te ne görürsün

Releases sayfası son 30 günü en yeniden eskiye doğru listeler: sürüm, CI'dan mı yoksa uygulamadan mı geldiği, deploy zamanı, her bir Core Web Vital için p75 değeri, önceki sürüme göre delta ve canlı bütçe durumu.

Sürüm detayı deploy öncesi kontrolü en üste koyar (taranan sayfa ve bütçe kalemi başına bir satır), altına da tüm siteye karşı o sürümü yerleştirir.

Performance Snapshots grafikler üzerine deploy işaretçileri çizebilir. İşaretçiler yalnızca yayına giren sürümler için görünür, böylece bloke edilmiş bir build asla hizmet vermediği trafiğin yanında görünmez.

Ayrıca bakınız: Bu verileri bir betikten veya bir AI ajanı üzerinden sorgulamak için Core/Dash API, bu kararların kullandığı bütçeler için alerts and notifications ve tracker sitende henüz yoksa installation.