Was ein MigrateForge-Evidenzbericht zeigt
Was der Bericht vor dem Cutover abdeckt — Antworten, Datenbankschreibvorgänge, ausgehende API-Aufrufe und die Reisen, die tatsächlich aufgezeichnet wurden.
Der Evidenzbericht ist das Dokument, das entscheidet, ob eine Welle cutovern darf. Er listet, was verifiziert wurde.
Die drei Vergleiche
Für jede aufgezeichnete Reise deckt der Bericht ab:
- Antworten. Was das PHP-System zurückgab, und was das Java-System zurückgab.
- Datenbankschreibvorgänge. Die Zeilen, die das PHP-System änderte, und die Zeilen, die das Java-System änderte.
- Ausgehende API-Aufrufe. Die Nachrichten, die das PHP-System sandte, und die Nachrichten, die das Java-System sandte.
Eine Reise ist verifiziert, wenn diese drei übereinstimmen. Dieselbe Regel blockiert den Cutover: beide Systeme in einer deterministischen Sandbox erneut abspielen, und eine Welle nicht umschalten, solange eine aufgezeichnete Reise noch abweicht.
Wie man ein Bestehen liest
Ein Bestehen heißt: die aufgezeichneten Reisen in dieser Welle stimmten überein. In der bisher veröffentlichten Arbeit erreichten vier migrierte Wellen über zwei PHP-Anwendungen 100/100/100-Parität auf 858 verifizierten Reisen, und jeder Datenschreibvorgang wurde geprüft. Der öffentliche InvoicePlane-Benchmark erreichte 100 % Parität auf Welle 1 und 2. Ein Bestehen ist keine Aussage über Reisen, die nie aufgezeichnet wurden.
Was der Bericht weglässt
Er sagt nicht, dass jedes mögliche Verhalten des alten Systems ausgeübt wurde. Wurde eine Reise nicht aufgezeichnet, steht sie nicht im Bericht. Der ehrliche nächste Schritt ist: aufzeichnen, erneut abspielen und das Gate seine Arbeit machen lassen.
Was Sie sonst behalten
Der Bericht steht neben drei weiteren Ergebnissen: dem Java-Spring-Boot-Code, den Defekten, die der Checker gefunden hat, und Anforderungen, die aus der laufenden PHP-Anwendung reverse-engineert wurden. Die Defekte sind die Abweichungen. Sie sind der Grund, warum eine Welle wartet.