Expand-Contract
Eine gleichzeitige Vertragsänderung kann laufende alte und neue Versionen inkompatibel machen.
- ExpandExpand: Neue Schnittstelle bleibt mit der alten kompatibel.
- MigrateMigrate: Nutzer und Daten wechseln schrittweise.
- ContractContract: Alte Form entfällt nach belegter Nutzung.
Einordnung
Warum das wichtig ist
Vertragsänderungen während schrittweiser Auslieferung kompatibel halten.
Vertragsänderungen während schrittweiser Auslieferung kompatibel halten.
Expand-Contract: Entscheidung prüfen
Das Shop-Beispiel nutzt die bestehende gemeinsame Datenbank und sieben Module. Jede ergänzte Dienst- oder Betriebsform ist eine hypothetische Erweiterung. Der Shop soll `delivery_note` durch `shipment_reference` ersetzen. Zuerst ergänzt eine Datenbankmigration die neue Spalte, und die Anwendung liest beide Felder. Im nächsten Release schreibt sie beide Werte und ein Hintergrundlauf füllt bestehende Bestellungen nach. Metriken zeigen, dass alle Instanzen die neue Spalte verwenden; danach entfernt ein gesondertes Contract-Release die alte Spalte. Der Ablauf erlaubt Rollback während der Migration und trennt die destruktive Änderung zeitlich vom ersten Deployment.
So liest du das Bild
- Expand Expand
- Migrate Migrate
- Contract Contract
| Begriff | Bedeutung | Prüffrage |
|---|---|---|
| Expand | Neue Schnittstelle bleibt mit der alten kompatibel. | Welcher Schritt füllt `shipment_reference` für bestehende Bestellungen? |
| Migrate | Nutzer und Daten wechseln schrittweise. | Welcher Nachweis erlaubt den Contract-Schritt? |
| Contract | Alte Form entfällt nach belegter Nutzung. | Warum liegt das Löschen des alten Felds in einem späteren Release? |
Nutzen & Grenzen
Hilft, wenn
- Vertragsänderungen während schrittweiser Auslieferung kompatibel halten.
- Expand, Migration und Contract als getrennte überprüfbare Schritte planen.
Grenzen
- Der Parallelbetrieb erhöht vorübergehend Komplexität und muss aktiv beendet werden.
- Destruktive Contract-Schritte warten auf alle alten Leser, Schreiber, Jobs und Rollback-Versionen.
In der Praxis
- Ergänze `shipment_reference` zunächst kompatibel und lies beide Spalten; prüfe, dass alte und neue Anwendungsinstanzen während des ersten Releases dieselben Bestellungen verarbeiten.
- Schalte danach Doppelschreiben und Hintergrundmigration ein, vergleiche Zeilenzahlen und Werte und beobachte Fehler, bis alle Instanzen zuverlässig das neue Feld verwenden.
- Entferne `delivery_note` erst in einem späteren Contract-Release nach geprüftem Backup- und Rollbackpfad; dokumentiere die Metrik, die den Zeitpunkt für diese Freigabe belegt.
Ausführliche Erklärung lesen
Expand-Contract teilt eine inkompatible Schema- oder Schnittstellenänderung in kompatible Releases auf. Zuerst wird die neue Form ergänzt, dann wechseln Nutzer und Daten kontrolliert, anschließend entfernt ein Contract-Schritt die veraltete Form.
Während der Übergangszeit müssen alte und neue Anwendungsversionen mit dem gemeinsamen Vertrag arbeiten können. Rückwärtskompatibilität, Datenabgleich, Messung verbliebener Altzugriffe und ein klarer Abschluss verhindern, dass die Übergangsphase zum Dauerzustand wird.
Das Shop-Beispiel nutzt die bestehende gemeinsame Datenbank und sieben Module. Jede ergänzte Dienst- oder Betriebsform ist eine hypothetische Erweiterung. Der Shop soll `delivery_note` durch `shipment_reference` ersetzen. Zuerst ergänzt eine Datenbankmigration die neue Spalte, und die Anwendung liest beide Felder. Im nächsten Release schreibt sie beide Werte und ein Hintergrundlauf füllt bestehende Bestellungen nach. Metriken zeigen, dass alle Instanzen die neue Spalte verwenden; danach entfernt ein gesondertes Contract-Release die alte Spalte. Der Ablauf erlaubt Rollback während der Migration und trennt die destruktive Änderung zeitlich vom ersten Deployment. datenmigration und deployment helfen, diese Entscheidung mit benachbarten Fragen zu vergleichen.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welcher Schritt füllt `shipment_reference` für bestehende Bestellungen?
Lösung mit Begründung ansehen
Ein Hintergrundlauf nach dem parallelen Schreiben beider Felder.
AnwendenAuf eine neue Lage übertragen
Welcher Nachweis erlaubt den Contract-Schritt?
Lösung mit Begründung ansehen
Metriken zeigen keine alten Leser oder Schreiber mehr, einschließlich Jobs und Rollback-Versionen.
BewertenEine Alternative abwägen
Warum liegt das Löschen des alten Felds in einem späteren Release?
Lösung mit Begründung ansehen
So bleiben alte und neue Anwendungsversionen während Migration und Rollback kompatibel.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Parallel Change (öffnet in neuem Tab)Beschreibt Expand, Migration und Contract als kompatible Änderungsschritte.
- Evolutionary Database Design (öffnet in neuem Tab)Erklärt parallele Schemaentwicklung und Übergangsphasen.
- Prisma data migration guide (öffnet in neuem Tab)Dokumentiert Expand-Contract für eine konkrete Datenbankschemaänderung.