backend-Verhalten beweisen

Lass eine repräsentative Fixture durch die echte backend-runtime laufen, erfasse die Evidenz und entscheide pass oder fail, bevor du promotest.

TL;DR

• Ein Beweis ist eine Test-und-Verifiziere-Schleife: eine repräsentative Fixture läuft durch die echte backend-runtime, erzeugt das erwartete Verhalten und hinterlässt erfassbare runtime-Signale. „Es kompiliert" ist kein Beweis.
• Die Schleife hat dieselbe Form, egal was du beweist — eine neue component-Release, ein trainiertes Modellartefakt, ein Datenpipeline-backend, eine graph-Revision: das zu testende Element identifizieren, die Fixtures einfrieren, sie durch die tatsächliche runtime laufen lassen, Ausgaben und runtime-Signale sammeln, gegen semantische Erwartungen vergleichen, die Evidenz festhalten.
• Ein Beweis pinnt die Operationshistorie eines backend, sodass die spezifische getestete Version später adressierbar bleibt — „die Version, die wir gestern getestet haben" löst auf einen exakten graph auf. Reproduzierbarkeit stammt aus dem event-sourced Operationslog, das auf denselben graph wiedergibt, gegen dieselben gepinnten Releases und dieselben Fixtures.
• Die Plattform liefert die Primitive, die einen Beweis reproduzierbar machen — gepinnte Releases, deterministische graphs, isolierte leases für ephemere Test-backends, Container-Logs — und überlässt die Definition von „besteht" dir. Du definierst die Erwartungen; die Plattform macht sie wiederholbar.
• Semantische Korrektheit zählt mehr als Schema. Ein Detektor, der gültiges JSON mit den falschen Labels ausgibt, ist kaputt; ein Transkriptionsmodell, das wohlgeformten Text in der falschen Sprache erzeugt, ist kaputt. Beim Beweis geht es um Bedeutung, nicht um Form.
• Beweis geht dem promote voraus. Dasselbe Fixture-Set läuft gegen den Kandidaten und den Amtsinhaber; das Delta ist die Evidenz, auf der die promote-Entscheidung ruht.

Einen Beweismodus wählen

Vier Ausgangspunkte — öffne den, der zu dem passt, was du beweist. Jeder verlinkt auf die Schleife, die ihn trägt.

Was ein Beweis ist

Ein Beweis ist eine benannte, wiederholbare Schleife, die eine Änderung — eine component-Release, ein Modellartefakt, ein Datenpipeline-backend, eine graph-Revision — in reproduzierbare Evidenz verwandelt, bevor diese Änderung Produktion oder promote erreicht. Die Ausgabe ist ein festgehaltenes Ergebnis: das zu testende Element, die Fixture, das erwartete Verhalten, das beobachtete Verhalten, das runtime-Signal und eine Schlussfolgerung.

Den Beweis in seiner eigenen Schleife zu halten ist es, was die Evidenz reproduzierbar macht. Jede promote braucht Evidenz; diese Evidenz muss dieselben Fixtures gegen dieselben gepinnten Versionen auf derselben runtime, die echter Traffic sehen wird, neu ausführen. Die Operationshistorie eines backend ist ein event-sourced Log, sodass der getestete graph im Nachhinein adressierbar ist — das Log gibt auf denselben graph wieder, und „die Version, die wir gestern getestet haben" zeigt auf einen exakten Satz von Operationen statt auf ein bewegliches Ziel.

Beweis unterscheidet sich vom Testen im Unit-Test-Sinne. Unit-Tests führen Code isoliert aus; ein Beweis lässt den tatsächlichen graph auf der tatsächlichen runtime mit repräsentativen Inputs laufen. Ein Unit-Test kann bestehen, während das integrierte System scheitert, weil der Test die Integration nie gesehen hat. Ein Beweis sieht immer die Integration, weil die Integration das Einzige ist, durch das er läuft.

Was als Evidenz zählt

Ein Beweis hält sechs Dinge fest; das Weglassen eines davon hinterlässt dir ein Ergebnis, keine Evidenz:

Evidenz	Was festzuhalten ist	Warum es zählt
Zu testendes Element	component-Versions-ID, Modellartefakt-ID, backend-ID (oder das Operationsset, das es mutierte), Fixture-Identität	„Die OCR-component" ist nicht spezifisch genug; die released-Version ist es
Input	Die Fixture selbst, adressierbar und unveränderlich	Ein Beweis, den du im nächsten Quartal nicht gegen dieselbe Fixture neu ausführen kannst, ist nicht reproduzierbar
Erwartetes Verhalten	Was die Ausgabe bedeuten soll, nicht welche Form sie haben soll	„Erkennt Gesichter im Bild" ist semantisch; „liefert ein JSON-Array" ist nur strukturell
Beobachtete Ausgabe	Die tatsächliche von der runtime erfasste Antwort, einschließlich generierter Dateien	Das ist, was du gegen die Erwartung vergleichst
runtime-Signal	Container-Logs, Fehlerzeilen, Latenzbeobachtungen	Ohne es bleiben Kaltstart-Klippen, sporadische Fehler und Ressourcenerschöpfung verborgen
Schlussfolgerung	Pass / fail / Abweichung, mit den spezifischen Risiken benannt	„Pass" ohne eine Risikonotiz verbirgt die Teile der Fixture, die der Lauf nicht abdeckte

Die Plattform legt die Primitive für alle sechs offen; sie zu Evidenz zusammenzusetzen ist die Aufgabe der Beweisschleife.

Beweismodi im Detail

Unterschiedliche Ausgangspunkte erzeugen unterschiedliche Beweisformen. Die Karten oben verlinken direkt auf jede Schleife; die Abschnitte unten erklären, wann jeder Modus der richtige ist und was seine Evidenz vertretbar macht.

Live-Fixture durch ein Test-backend

Verwende diesen Modus, wenn das zu testende Element eine component-Release oder eine graph-Änderung ist und du einen schnellen reproduzierbaren Lauf mit automatischer Bereinigung willst.

Dies ist der Standardmodus für component-Autoren. Eine kurzlebige lease stellt ein Test-backend auf, das die Kandidaten-component umschließt, lässt die Fixture laufen, erfasst Ausgaben und Container-Logs und baut ab. Die lease ist die Isolationsgrenze: nichts am Testlauf berührt Produktions-graphs oder Produktions-deployments, und die Kandidaten-Version wird genau so beansprucht, wie ein echtes backend sie beanspruchen würde.

Weil das Test-backend dieselben backend-Primitive wie die Produktion nutzt, ist der Beweis getreu: typisierte Streams fließen durch den Kandidaten, die component sieht dieselbe containerisierte Umgebung, dieselben SDK-Helfer, dieselben Serving-Service-Abhängigkeiten. Es gibt keine „das funktioniert im Unit-Test, aber die runtime ist anders"-Lücke.

Siehe Mit einem laufenden backend testen und Leases.

Identische Fixtures gegen das modellgebundene backend

Verwende diesen Modus, wenn das zu testende Element ein Modellartefakt ist: Gewichte, Checkpoint, ONNX-Datei, Adapter oder Fine-Tune.

Modellbeweis ist selten „erzeugt es JSON". Es ist „erzeugt es die richtige Ausgabe auf den Inputs, die uns wichtig sind". Die Schleife ist: das Kandidatenartefakt hochladen, es in den Datei-Slot des Ziel-backend-vertex binden, das Fixture-Set laufen lassen, beobachtete Ausgaben gegen die semantische Erwartung vergleichen. Beim Upgrade eines Modells wird der Beweis gegen das vorherige Artefakt im selben backend wiederholt, und das Delta ist das Artefakt für die promote-Entscheidung.

Der Grund, warum sich dieser Modus von „Live-Fixture" unterscheidet, ist, dass das zu testende Element das Artefakt ist, nicht die component. Zwei Modellartefakte, die durch dieselbe component, denselben graph, dasselbe Fixture-Set laufen, isolieren das Artefakt als Variable — und diese Isolation ist es, die „dieses Artefakt ist besser als der Amtsinhaber" vertretbar macht.

Siehe Modellartefakt-Integration und Modelle.

Wiederholbare Daten-Fixture durch das backend

Verwende diesen Modus, wenn das zu testende Element eine Datenpipeline ist.

Datenpipeline-Beweis ist Fixture-Abdeckungs-Beweis: repräsentative Inputs werden durch das backend gelaufen, generierte Ausgaben erfasst, und der Lauf wird als nächste Regressions-Baseline behandelt. Weil das backend ein typisierter Echtzeit-graph ist, braucht die Beweisschleife keine separate Batch-Verarbeitungs-Harness — dasselbe backend, das in der Produktion geplanten Traffic ausführt, lässt die Fixture im Beweis laufen.

Der Grund, warum dieser Modus seine eigene Zeile ist, ist die Artefakt-Erfassungs-Gewohnheit: Pipeline-Beweise sind am nützlichsten, wenn die generierten Ausgaben den Abbau überdauern und zu den erwarteten Ausgaben des nächsten Laufs werden. Der deployment-Abbau kann generierte Dateien explizit in den Workspace-Dateispeicher sichern, was Pipeline-Beweis über Versionen der zugrundeliegenden components hinweg reproduzierbar macht.

Siehe Datenpipeline-Automatisierung und Datei-Upload und -Bindung.

Versionsvergleich

Verwende diesen Modus, wenn die promote-Frage lautet „ist der Kandidat besser als der Amtsinhaber".

Versionsvergleich ist dasselbe Fixture-Set, zweimal ausgeführt, gegen zwei gepinnte Elemente (zwei component-Versionen, zwei Modellartefakte, zwei backend-Revisionen), mit denselben semantischen Kriterien auf beide beobachteten Ausgaben angewendet. Das Ergebnis ist das Delta, nicht einer der Läufe isoliert. Ein Kandidat, der „gut", aber schlechter als der Amtsinhaber ist, sollte nicht promotet werden; ein Kandidat, der „unvollkommen", aber wesentlich besser als der Amtsinhaber ist, sollte es oft.

Die Plattform macht Versionsvergleich günstig, weil alles gepinnt und unveränderlich ist. Die Fixture ist adressierbar; die zwei zu testenden Elemente sind adressierbar; die runtime ist derselbe backend-graph mit einer getauschten Bindung. Es gibt keinen „haben wir versehentlich gegen eine andere Fixture verglichen"-Fehlermodus.

Siehe Release-Semantik.

Die Beweisschleife in Bewegung

Die minimale Sequenz ist kurz und sieht über alle Modi gleich aus:

1. Genau identifizieren, was getestet wird (Versions-IDs, Artefakt-IDs, backend-ID).
2. Das Fixture-Set einfrieren, damit dieselben Inputs später neu ausgeführt werden können.
3. Die Fixture durch die tatsächliche runtime laufen lassen — ein lease-gestütztes Test-backend für component-/graph-Beweis, ein deploytes backend für Modell-/Pipeline-Beweis.
4. Warten, bis jeder vertex-Container running meldet, bevor Input gesendet wird; URLs können auflösen, bevor die zugrundeliegenden Container lauschen.
5. Die Fixture senden, die beobachtete Ausgabe sammeln (einschließlich etwaiger generierter Dateien), die begleitenden Container-Logs erfassen.
6. Beobachtetes Verhalten mit der semantischen Erwartung vergleichen.
7. Die Evidenz festhalten — IDs, Fixture, erwartet, beobachtet, runtime-Signal, Schlussfolgerung, Abweichungsrisiken.

Wenn sich die runtime fehlverhält, sind die Container-Logs die Quelle der Wahrheit. Die Plattform synthetisiert bewusst keine vereinheitlichte „das ist schiefgegangen"-Oberfläche; sie legt die Container-Ausgabe wörtlich offen und lässt die Beweisschleife entscheiden, was als Fehlersignal zählt.

Warum Beweis das promote gatet

promote — eine prerelease in eine released-Version verwandeln, ein Modellartefakt in die Produktion tauschen, echten Traffic auf eine neue backend-Revision lenken — ist der Schritt, in dem eine Änderung beginnt, echten Traffic zu bedienen. Es ist reversibel, aber das Zurücksetzen hilft erst, sobald eine Regression bereits bemerkt wurde.

Beweis gatet das promote, weil die anderen Prüfungen die Fragen, von denen das promote abhängt, nicht beantworten können: Code-Review kann dir nicht sagen, ob ein Modell auf einem harten Teilsatz von Inputs regredierte, ein bestandener Build kann dir nicht sagen, ob der Container der neuen component beim Kaltstart hängt, ein manueller Smoke-Test kann dir nicht sagen, ob eine schema-korrekte Antwort noch dasselbe bedeutet. Eine evidenztragende Beweisschleife kann es.

Die Plattform behält das promote als expliziten, separaten Befehl — nie implizit im Publish, nie implizit im Deploy. Der promote-Aufruf ist die Stelle, an der ein Mensch sein Urteil an die Evidenz heftet, die die Beweisschleife erzeugt hat.

Verwandt

• Mit einem laufenden backend testen — der Standard-Test-Harness-Modus.
• Leases — Isolationsgrenze für ephemere Test-backends.
• Modellartefakt-Integration — modellgebundene Beweisschleife.
• Datenpipeline-Automatisierung — Pipeline-Beweisschleife.
• Release-Semantik — was das promote tatsächlich ändert.
• Deployen und überwachen — runtime-Signal-Erfassung während des Beweises.
• Häufige Fehler — Symptom → Behebung-Nachschlag.