Canlı bir backend ile test et

Canlı test çıktıları doğrulama sırasında lease-owned kalır. Commit ve Rollback üretilen çıktı dosyalarını siler. Seçili bir çıktı yalnızca açık istek üzerine, kapatmadan önce lease promote ile tutulur. Lease sonucu dosya adlarını, boyutları, SHA-256 özetlerini ve doğrulama çıkış koduyla çıktısını saklar.

Canlı bir backend ile test et

Özet

• Bir canlı backend testi, aday component'i (veya model artifact'ini veya grafik değişikliğini) üretimin kullandığı aynı runtime üzerinde, etrafına sarılı bir I/O harness ile çalıştırır. Aday, üretim container ortamında, üretim tipli stream'ler üzerinde, sahte taşıma olmadan ve ayrı bir test SDK'sı olmadan çalışır.
• Kanonik döngü manifest güdümlüdür: ppl lease run --test=<manifest> --runtime=<id> bir lease basar, çalışma dizininden bir prerelease yayınlar, yerel fixture'ları yükler, bir live-test olay akışı açar ve sonunda lease'i rollback yapar. Tek fazlı runner için kaydedilmiş başarılı completed, runner'sız veya tamamlanmış çok fazlı koşu için terminal ready çıkış 0 verir; hatalar hata koduna göre sınıflandırılmış sıfırdan farklı çıkış verir.
• Harness şekli, kenarlarda input_<format>_http / output_<format>_http component'leri olan girdi ⇒ CUT ⇒ çıktı'dır. Girdiler HTTP POST'tur; çıktılar WebSocket çerçeveleridir (serileştirilebilir tipler için JSON, medya için önce-metadata-sonra-ikili).
• Bir lease temizleme kontratıdır: test backend'i, prerelease, geçici fixture'lar ve deployment'ın hepsi lease içinde yaşar ve lease kapandığında birlikte kaldırılır. TTL, test koşucusu erken çıksa bile yıkmayı garanti eder.
• El yapımı yol (backend create / add-vertex / connect / change-parameter / deploy), manifest dilbilgisinin ifade edemediği durumları kapsar — tek seferlik grafikler, önceden var olan harness kombinasyonları, standart dışı test koşucuları.

Canlı backend testi nedir

Bir canlı backend testi, aday component'i üretimde çalışacağı runtime üzerinde, gerçek bir backend grafiği içinde, fixture'ların içeri akabilmesi ve sonuçların dışarı akabilmesi için etrafına sarılı bir I/O harness ile çalıştırır. Aday, üretimde gördüğü aynı container'lanmış ortamı, aynı tipli stream'leri ve aynı serving-service bağımlılıklarını görür. Harness component'leri (input_<format>_http, output_<format>_http) kendileri release edilmiş component'lerdir, dolayısıyla test yolu ve üretim yolu aynı yoldur.

Bu, hızlı geri bildirim ile gerçekçi bir ortam arasındaki olağan ödünleşmeden kaçınır. Sahte bir model, gerçek model hakkında hiçbir şey kanıtlamayan hızlı bir test verir; bir notebook'ta elle çalıştırılan bir model gerçekçidir ama hiçbir izolasyon, yeniden üretilebilirlik veya CI hikâyesi sunmaz; ayrı bir "test modu" SDK'sı zamanla üretimden uzaklaşır. Bir canlı backend testi, bunların hiçbiri olmadan gerçekçi ortamı korur.

lease, bunu bir CI deseni olarak pratik kılan şeydir. Test başına ayağa kaldırılan gerçek bir backend aksi takdirde sızıntı yapardı — backend, deployment ve geçici fixture'ların hepsi kalıcı olurdu ve her CI çalıştırması arkasında yetim bırakırdı. Bir lease içinde, tüm aparat birlikte kaldırılan tek bir sahipli kapsamdır, dolayısıyla test hem gerçekçi hem de temizdir.

Bunun arkasındaki sahiplik modeli için Lease'ler ve lease yaşam döngüsü'ne bak.

Harness şekli

fixture
   │
   ▼
input_<fmt>_http ──► CUT (component under test) ──► output_<fmt>_http
   (POST or WS)      (the candidate)                 (WS frames)

Harness, aday component'e gerçek bir girdi kaynağı ve gerçek bir çıktı sink'i verir, böylece test, üretimin yaptığı gibi tipli stream'leri çalıştırır. Input component'i bir HTTP isteği alır ve CUT'un girdi portuna tipli bir stream yayar. Output component'i CUT'un çıktı stream'ini tüketir ve onu testin okuyabileceği bir WebSocket çerçevesi olarak yayar.

Harness, normal bir backend üzerinde vertex'ler olarak eklenen iki normal release edilmiş component'tir — özel altyapı değil. Her uçtaki vertex'i değiştirerek farklı harness component'lerini (ses CUT'u için bir Input Audio HTTP, görüntü yayan bir CUT için bir Output Image HTTP) yer değiştirirsin. Şekil aynı kalır. output_type'sız bir CUT — log-message gibi bir sink — hâlâ canlı test edilebilirdir: harness tarafından okunabilir bir çerçeve üretmez, dolayısıyla bunun yerine container log'larına karşı assertion yaparsın.

Birini çalıştırmanın iki yolu

Aynı canlı teste iki yol vardır. Onu tekrarlayıp tekrarlamayacağına göre seç.

Yol 1 — manifest güdümlü (ppl lease run --test=…)

Bu yolu tekrarlamak istediğin her şey için kullan: CI, regresyon paketleri, kanıt döngüleri, sürüm karşılaştırmaları.

Manifest testi bildirimsel olarak tanımlar: adayın ne olduğu, hangi fixture'ları görmesi gerektiği, etrafını hangi grafiğin sardığı ve hangi çıktıların yakalanması gerektiği. CLI manifesti okur, gerekirse adayı yayınlar, yerel fixture'ları yükler, live-test olay akışını açar ve test bir terminal duruma ulaşana kadar sunucu olaylarını NDJSON olarak yayar.

ppl lease run --test=tests/live-test.yml --runtime=<runtime_id>Copy

CLI manifesti ayrıştırır, isteğe bağlı CUT prerelease'ini yayımlar, yerel fixture'ları yükler ve canlı test olaylarını NDJSON olarak aktarır. Yalnızca tüm runner'lar başarılı olup test sonucu kaydedildikten sonra 0 ile çıkar. Runner, build veya bağlantı hatasında sıfırdan farklı kodla çıkar.

--cut-version-id, cwd'den bir tane yayınlamak yerine testi belirli bir prerelease'e yönlendirir. --label lease etiketini ayarlar (sonraki toplu temizlik için kullanılır). --ttl lease'in ömrünü cap'ler (sunucu bir default artı sabit bir cap uygular). Çalıştırma çıktığında lease her zaman rollback yapar.

Manifest

Manifest, tüm çalıştırmanın bildirimsel bir tanımıdır. vertices bölümü kenarlardaki harness component'lerini adlandırır ve CUT vertex'ini işaretsiz bırakır — harness'sız bir vertex CUT'tur. edges bölümü onları bağlar. Fixture'lar isimle iliştirilir ve path / url / file_id'den tam olarak birine çözümlenir. secret'lar workspace secret'larını vertex parametrelerine bağlar. output files, platformun yıkma sırasında hangi üretilen dosyaları workspace'e kaydetmesi gerektiğini beyan eder.

release:  auto: true                    # CLI publishes a prerelease from cwddeploy:  fixed_duration: 10m           # Pin deployment lifetime (Go duration)  lease_ttl: 30m                # Whole-lease TTL (server caps)fixtures:  - {name: dog, path: ./tests/dog.jpg}secrets:  - {vertex: cut, key: HF_TOKEN, workspace_secret: hf_token}graph:  vertices:    in:  {harness: "Input Image HTTP"}    cut: {params: {model_cfg: {type: String, value: '"fastvit_t8"'}}}    out: {harness: "Output JSON HTTP"}  edges:    - {from: in,  from_output: 0, to: cut, to_input: 0}    - {from: cut, from_output: 0, to: out, to_input: 0}output_files:  - {name: report, vertex: cut, key: report.json}cmd: [python3, tests/test_backend.py]      # runner: deployment'ı sürer, çıktının içeriğini doğrularverify: [python3, tests/verify_files.py]   # doğrulayıcı: yıkımdan sonra çıktı dosyalarını kontrol eder

Tests düzeni

Bir component'in tests/ dizini tam olarak tests/live-test.yml manifest'ini; ready bağlamını stdin'den okuyan, deployment'ın endpoint'lerini süren ve her çıktının içeriğini doğrulayan, her vakası (boş, dejenere, bozuk, sınır, büyük ve gerçek girdiler, her çıktı kolu, girdi başına bir çıktı) içinde yazılı runner'ı tests/test_backend.py'ı; çalıştırma sink'lerinin yazdığı dosyaları kontrol ettiğinde tests/verify_files.py'ı; ve bunların okuduğu fixture'lar ile referans verilerini içerir. cmd her zaman [python3, tests/test_backend.py], ardından yalnızca runner'ın kendi argümanlarıdır; verify ise [python3, tests/verify_files.py]'dır.

tests/ altında hiçbir yerde shell betiği, derlenen (C++ ya da başka) birim testi ve component'in yanında yardımcı betik yoktur: runner'ın canlı deployment'a karşı çalıştırmadığı bir vaka version hakkında hiçbir şey kanıtlamaz. Release kontrol listesi kuralı build.layout her sorunlu dosyayı ve argv'yi adıyla bildirir, ppl component validate da bunu release'den önce raporlar.

Dış servise bağlanan component

Secret parametresi olan component gerçek dış servise karşı test edilir. Parametreyi workspace_secret ile bağlayın (ppl secret list) ve gerçek endpoint adresini koruyun. CUT üzerinde fixture_value veya graph'ın başka vertex'ine yönelen parametre ya da service_hosting endpoint'i canlı kanıt sayılmaz. proof.live, güncel yürütme girdilerine karşı runner'ı 0 ile çıkan en son tamamlanmış başarılı koşuyu gerektirir. Servisteki fixture'ları test oluşturur ve kaldırır: aynı workspace secret'ını secret parametresine bağlayan inline transform vertex'leri ayrı fazlarda çalışır. İlk faz testin kendi alanını temizler ve fixture'ları oluşturur, CUT fazı okur, son faz kaldırır. Seed vertex'i her girdide çalışır; runner input harness'a tam bir tick gönderir.

Olay akışı

Sunucu, test kurulumunun her adımını live-test akışı üzerinden raporlar. Her olay bir type alanı olan bir JSON nesnesidir; CLI onları aynen, satır başına bir tane yazdırır.

type	Anlamı
lease_created	Sunucu bu çalıştırma için bir lease bastı.
fixture_fetched	Her URL modu fixture için bir tane.
backend_created	Sunucu bir backend id atadı.
vertex_added	Her vertex için bir tane; sunucu tarafından atanan vertex_id'yi taşır.
edge_connected	Her kenar için bir tane.
param_set	Ayarlanan her vertex parametresi için bir tane.
file_bound	Her vertex dosya bağlaması için bir tane.
deploy_started	deployment id basıldı.
container	Ayağa kaldırılan her container için bir tane.
ready	Runner bağlamı; runner yoksa veya tüm fazlar bittiyse terminaldir.
completed	Tek fazlı runner sonucu kaydedildi; başarılı runner çıkış 0'a izin verir.
failed	Terminal başarısızlık. Payload {stage, error, debug_bundle?}. CLI hata koduna göre sınıflandırılmış sıfırdan farklı bir çıkış kodu döndürür.

Akış test kurulumunu kapsar; fixture-içeri / sonuç-dışarı alışverişi ready sonrası forward edilen endpoint'lere karşı gerçekleşir. Assertion'larını her vertex_added olayında taşınan sunucu tarafından atanan vertex_id'ye geri eşle.

Yol 2 — el yapımı backend

Bu yolu, manifest dilbilgisi testi tanımlayamadığında kullan: tek seferlik grafikler, şemanın kapsamadığı harness kombinasyonları veya manifest akışının gömmediği bir koşucuda yazılmış sürücüler.

El yapımı yol, platformun dahili olarak kullandığı aynı CLI primitive'lerini kullanır: bir backend oluştur, input / CUT / output vertex'lerini ekle, portlarını bağla, CUT'un ihtiyaç duyduğu parametreleri bağla ve deploy et.

PID=$(ppl backend create --name "live test $(date +%s)" | jq -r .data.backend_id)Copy# component versions returns a bare JSON array (no {count, items} envelope):INPUT_V=$(ppl component versions <input_component_id>  | jq -r '.[] | select(.tags[]? == "latest") | .id')CopyCUT_V=$(ppl component versions <cut_component_id>      | jq -r '.[] | select(.tags[]? == "latest") | .id')CopyOUTPUT_V=$(ppl component versions <output_component_id> | jq -r '.[] | select(.tags[]? == "latest") | .id')Copy# add-vertex has no vertex-id flag — the server assigns it and returns# it in .data.vertex_id. Capture each id for the connect calls.IN=$(ppl  backend add-vertex $PID --version $INPUT_V  --alias in  | jq -r .data.vertex_id)CopyCUT=$(ppl backend add-vertex $PID --version $CUT_V    --alias cut | jq -r .data.vertex_id)CopyOUT=$(ppl backend add-vertex $PID --version $OUTPUT_V --alias out | jq -r .data.vertex_id)Copyppl backend connect $PID --from-vertex $IN  --from-output 0 --to-vertex $CUT --to-input 0Copyppl backend connect $PID --from-vertex $CUT --from-output 0 --to-vertex $OUT --to-input 0Copyppl backend change-parameter $PID --vertex $CUT --name model_cfg \    --type String --value '"fastvit_t8"'Copyppl backend deploy --runtime <runtime_id> --backend $PIDCopy

Bu fiiller bir lease'e iliştirilmez — yalnızca manifest güdümlü lease run yolu backend'i, prerelease'i, fixture'ları ve deployment'ı birlikte rollback yapan tek bir lease-sahipli kapsam olarak damgalar. Dolayısıyla yukarıdaki el yapımı dizi, kaynakları elle attığın (ppl backend undeploy --backend $PID, ardından ppl backend delete $PID) tek seferlik keşif için olan biçimdir. Otomatik temizlemeli tekrarlanabilir bir CI döngüsü için Yol 1'i kullan.

Harness'ı seçme

Her taraftaki harness, CUT'un I/O tipiyle eşleşmek zorundadır:

CUT girdi tipi	Harness ingress
Image	Input Image HTTP (çıktı 0 = Image)
AudioFrame	Input Audio HTTP
Tensor	Input NumPy HTTP
serileştirilebilir herhangi bir şey	Input JSON HTTP (çıktı 0 = t)

CUT çıktı tipi	Harness egress
Image	Output Image HTTP
Polygon<Double>	Output JSON HTTP
[BoundingBox]	Output JSON HTTP
genel herhangi bir şey	Output JSON HTTP

Output JSON HTTP default egress'tir: herhangi bir backend-tipli mesajı kabul eder ve onu WebSocket üzerinde JSON'a serileştirir; bu, testlerde en kolay assertion yapılan şekildir. CUT bir Image yaydığında ve ham baytları istediğinde Output Image HTTP'yi (önce-metadata-sonra-ikili çerçeve protokolü) kullan.

Harness component'lerini sorguyla keşfet — yalın list sınırı 20 kayıttır ve --query bunun ötesinde arar:

ppl component list --query=InputCopyppl component list --query=OutputCopy

Testi sürme

deploy sonrası, endpoint URL'lerini ppl forward $PID ile al. Her satır endpoint_name'i (harness component'inin http: bloğunda beyan ettiği şey), vertex_id'yi, url'yi ve token'ı taşır. URL'yi ve token'ı bearer kimlik bilgileri olarak ele al; onları loglamak yerine test sürücüne ortam değişkenleri olarak geçir.

Çıktı URL'si HTTP'dir, ama testler ona WebSocket olarak bağlanır (https:// → wss://). Girdi URL'si düz HTTP POST'tur. Çıktı WebSocket'ini girdiyi göndermeden önce aç — aksi takdirde yanıt, okuyucu hâlâ bağlanırken gelebilir ve test onu kaçırır. Output JSON HTTP için backend mesajı başına bir metin çerçevesi JSON gövdesini taşır; Output Image HTTP için bir metin çerçevesi {"type": "metadata", "metadata": {…}} (anahtarlar metadata_keys üzerinden yapılandırılabilir) ardından görüntü baytlarını taşıyan bir ikili çerçeve gelir.

Zamanlama gerçekleri

Taze bir backend deploy etmek 30 saniyeden 4 dakikaya kadar sürer — runtime'ın yerel registry'sinden image çekme, container başlatma, tip çıkarımı çalıştırma, endpoint kaydı. Soğuk runtime'lar bu aralığın üst ucunda oturur. CUT bir modeli tembel yüklüyorsa (HuggingFace çekme, ONNX başlatma, Triton model yükleme), deploy sonrası ilk istek ek 10–30 saniye sürebilir. Test sürücüleri ilk istek için çerçeve başına okuma timeout'larını ≥30 saniye ayarlamalı ve soğuk başlatma zamanını test başına değil, harness düzeyinde bütçelemeli.

Bu sayılar test tasarımını şekillendirir çünkü her taze backend onları tekrar öder — backend'ler arasında amortize olmazlar. Bunlara saygı duyan bir CI paketi, fixture başına yeni bir backend ayağa kaldırmak yerine bir backend ayağa kaldırır, ona karşı birçok fixture çalıştırır ve onu yıkar. Manifest yolu bunu doğrudan destekler: bir lease tüm çalıştırma için bir deployment tutar.

Test başarısız olduğunda

Başarısızlıklar küçük bir şekiller kümesine düşer:

• Bir connect kenarında tip uyumsuzluğu — platform grafiği deploy öncesi reddetti. Hata kenarı ve çakışmayı adlandırır; bağlantıyı düzelt (genellikle uyumsuz ama uyumlu tipler arasında eksik bir transformation).
• endpoint çözümleniyor ama POST 404 döndürüyor — backend hâlâ deploy ediyor. Girdi göndermeden önce container'lar running olana kadar yokla.
• WebSocket okumaları timeout oluyor — CUT container içinde çöktü. Log'larını oku (ppl deployment logs --container <container_id>).
• WebSocket bağlanıyor ama çerçeve gelmiyor — CUT çalışıyor ama sessizce başarısız oluyor (istisna yok, emit yok). Bir sonraki adım component düzeyinde loglamadır.
• Deploy "no nodes available" ile reddediyor — runtime'ın aday için GPU veya RAM boşluğu yok. Farklı bir runtime seç veya bekle.

Daha geniş desenler için Yaygın hatalar'a bak.

Bunun uyduğu yer

Bir canlı backend testi, build ile ship arasındaki kanıt adımıdır. Aday component'in, model artifact'inin veya grafik revizyonunun üretimde çalışacağı runtime üzerinde doğru davranıp davranmadığını yanıtlar. runtime üretimle aynıdır ve lease temizlemeyi garanti eder, dolayısıyla sonuç hem gerçekçi hem de tekrarlanabilirdir — bir promote kararının ihtiyaç duyduğu kanıt.

Manifest yolu bu döngüyü elle sürülen bir dizi yerine bir CI adımına dönüştürür. El yapımı yol, manifest dilbilgisine uymayan testleri kapsar. İkisi de aynı kanıtı üretir; yalnızca testi nasıl tanımladığında farklılaşırlar.

İlgili

• Davranışı kanıtla — hepsi bu döngünün üzerine kurulan daha geniş kanıt modları (model entegrasyonu, veri pipeline'ları, sürüm karşılaştırması).
• lease yaşam döngüsü — her live-test çalıştırmasının arkasındaki temizleme kontratı.
• Lease'ler — geçici kaynaklar için sahiplik modeli.
• Deploy et ve izle — bu döngünün geçici olmayan karşılığı.
• Backend'ler — testin sardığı grafik.
• Yaygın hatalar — belirti → çözüm araması.