Regenerationssichere Schemaentwicklung für vorhersehbare Migrationen

Warum Schemaänderungen mit regeneriertem Backend riskant wirken

Wenn dein Backend aus einem visuellen Modell regeneriert wird, kann eine Datenbankänderung sich anfühlen wie an einem Faden zu ziehen, der einen Pullover aufribbeln könnte. Du änderst ein Feld im Data Designer, klickst auf Regenerate und plötzlich veränderst du nicht nur eine Tabelle. Du veränderst auch die generierte API, Validierungsregeln und die Abfragen, die deine App zum Lesen und Schreiben nutzt.

Was meist schiefgeht, ist nicht, dass der neue Code nicht kompiliert. Viele No‑Code‑Plattformen (einschließlich AppMaster, das echten Go‑Code für Backends generiert) erzeugen bei jeder Regeneration gerne ein sauberes Projekt. Das eigentliche Risiko ist, dass in Produktion bereits Daten existieren, und diese sich nicht automatisch so umformen, wie du es dir vorstellst.

Die zwei Fehler, die als erstes auffallen, sind simpel:

• Zerbrochene Lesevorgänge: Die App kann Datensätze nicht mehr laden, weil eine Spalte verschoben wurde, ein Typ sich geändert hat oder eine Abfrage etwas erwartet, das nicht vorhanden ist.
• Zerbrochene Schreibvorgänge: Neue oder aktualisierte Datensätze schlagen fehl, weil Constraints, Pflichtfelder oder Formate sich geändert haben und bestehende Clients noch die alte Form schicken.

Beide Fehler sind schmerzhaft, weil sie sich bis zum Auftreten realer Nutzer verbergen können. Eine Staging‑Datenbank ist vielleicht leer oder frisch befüllt, also sieht alles gut aus. Produktion hat Randfälle: NULLs, wo du Werte erwartet hast, alte Enum‑Strings oder Zeilen, die vor einer neuen Regel angelegt wurden.

Deshalb ist regenerationssichere Schema‑Evolution wichtig. Das Ziel ist, jede Änderung so vorzubereiten, dass sie sicher ist, selbst wenn der Backend‑Code komplett regeneriert wird — alte Datensätze bleiben gültig und neue Datensätze können weiter erzeugt werden.

„Vorhersehbare Migrationen" bedeutet einfach, dass du vor dem Deploy vier Fragen beantworten kannst: Was ändert sich in der Datenbank, was passiert mit bestehenden Zeilen, welche App‑Versionen können während des Rollouts noch funktionieren und wie rollst du zurück, falls unerwartetes auftaucht.

Ein einfaches Modell: Schema, Migrationen und regenerierter Code

Wenn deine Plattform das Backend regenerieren kann, hilft es, drei Dinge klar zu trennen: das Datenbankschema, die Migrationsschritte, die es verändern, und die Live‑Daten, die bereits in Produktion liegen. Das Vermischen dieser Dinge macht Änderungen unvorhersehbar.

Denk an Regeneration als „den Anwendungscode aus dem aktuellsten Modell neu bauen“. In einem Tool wie AppMaster kann das viele Male während normaler Arbeit passieren: Du passt ein Feld an, veränderst Geschäftslogik, fügst einen Endpoint hinzu, regenerierst, testest, wiederholst. Regeneration ist häufig. Deine Produktionsdatenbank sollte das nicht sein.

Hier das einfache Modell:

• Schema: die Struktur deiner Datenbanktabellen, Spalten, Indizes und Constraints. Das ist, was die Datenbank erwartet.
• Migrationen: die geordneten, wiederholbaren Schritte, die das Schema von einer Version zur nächsten bringen (und manchmal auch Daten verschieben). Das ist, was du in jeder Umgebung ausführst.
• Laufzeitdaten: die realen Datensätze, die von Nutzern und Prozessen erzeugt wurden. Sie müssen vor, während und nach der Änderung gültig bleiben.

Regenerierter Code sollte als „die aktuelle App, die mit dem aktuellen Schema spricht“ behandelt werden. Migrationen sind die Brücke, die Schema und Laufzeitdaten im Einklang hält, während sich der Code ändert.

Warum Regeneration das Spiel verändert

Wenn du häufig regenerierst, wirst du naturgemäß viele kleine Schema‑Änderungen vornehmen. Das ist normal. Das Risiko entsteht, wenn diese Änderungen eine nicht rückwärtskompatible Datenbank‑Änderung implizieren oder wenn deine Migration nicht deterministisch ist.

Eine praktische Methode ist, regenerationssichere Schema‑Evolution als Serie von kleinen, umkehrbaren Schritten zu planen. Statt eines großen Schalters machst du kontrollierte Schritte, die alte und neue Codepfade für kurze Zeit koexistieren lassen.

Beispiel: Wenn du eine Spalte umbenennen willst, die von einer Live‑API verwendet wird, benenne sie nicht sofort um. Füge zuerst die neue Spalte hinzu, schreibe in beide Spalten, fülle bestehende Zeilen nach, und wechsle dann die Lesevorgänge auf die neue Spalte. Erst danach entfernst du die alte Spalte. Jeder Schritt ist leicht zu testen und wenn etwas schiefgeht, kannst du pausieren, ohne Daten zu zerstören.

Dieses mentale Modell macht Migrationen vorhersehbar, selbst wenn Code‑Regeneration täglich passiert.

Arten von Schemaänderungen und welche Produktion brechen

Wenn dein Backend aus dem aktuellsten Schema regeneriert wird, nimmt der Code meist an, dass die Datenbank genau dieses Schema hat. Deshalb geht es bei regenerationssicherer Schema‑Evolution weniger um „Kann man die Datenbank ändern?“ und mehr um „Können alte Daten und alte Requests überleben, während wir die Änderung ausrollen?"

Einige Änderungen sind von Natur aus sicher, weil sie existierende Zeilen oder Abfragen nicht ungültig machen. Andere ändern die Bedeutung von Daten oder entfernen etwas, das die laufende App noch erwartet — dort passieren Produktionsvorfälle.

Niedriges Risiko, meistens sicher (additiv)

Additive Änderungen sind am einfachsten zu deployen, weil sie mit alten Daten koexistieren können.

• Neue Tabelle, von der noch nichts abhängt.
• Neue nullable Spalte ohne zwingende Default‑Anforderung.
• Neues optionales API‑Feld End‑to‑End.

Beispiel: Eine nullable Spalte middle_name zur Tabelle users hinzuzufügen ist typischerweise sicher. Bestehende Zeilen bleiben gültig, regenerierter Code kann sie lesen, wenn sie vorhanden sind, und ältere Zeilen haben einfach NULL.

Mittleres Risiko (Bedeutungsänderungen)

Diese Änderungen funktionieren technisch oft, brechen aber Verhalten. Sie brauchen Koordination, weil Regeneration Validierungen, generierte Modelle und Geschäftslogik anpasst.

Renames sind die klassische Falle: phone zu mobile_phone umzubenennen kann dazu führen, dass regenerierter Code phone nicht mehr liest, während Produktion die Daten noch dort hat. Ähnlich kann das Ändern von Einheiten (Preis in Dollar vs. Cent) stillschweigend Berechnungen verfälschen, wenn man Code vor oder nach den Daten ändert.

Enums sind ein weiterer scharfer Rand. Ein Enum einzuschränken (Werte entfernen) kann bestehende Zeilen ungültig machen. Ein Enum zu erweitern (Werte hinzufügen) ist meist sicher, aber nur, wenn alle Codepfade mit dem neuen Wert umgehen können.

Praktischer Ansatz: Bedeutungsänderungen als „neu hinzufügen, nachfüllen, umschalten, später entfernen“ behandeln.

Hohes Risiko (destruktiv)

Destruktive Änderungen brechen Produktion am häufigsten sofort, besonders wenn die Plattform Code regeneriert, der die alte Form nicht mehr erwartet.

Spalten oder Tabellen zu löschen oder eine Spalte von nullable auf NOT NULL zu ändern, kann Schreibvorgänge fehlschlagen lassen, sobald ein Request versucht, eine Zeile ohne diesen Wert einzufügen. Selbst wenn du denkst, „alle Zeilen haben den Wert“, kann der nächste Randfall oder ein Hintergrundjob das Gegenteil beweisen.

Wenn du eine NOT NULL‑Änderung durchführen musst, dann in Phasen: Spalte zuerst nullable hinzufügen, backfill durchführen, App‑Logik aktualisieren, die den Wert immer setzt, und erst dann NOT NULL erzwingen.

Performance‑ und Sicherheitsänderungen (können Schreibvorgänge blockieren)

Indizes und Constraints sind keine „Datenform“‑Änderungen, können aber trotzdem Ausfallzeiten verursachen. Einen Index auf einer großen Tabelle zu erstellen oder eine UNIQUE‑Constraint hinzuzufügen, kann Schreibzugriffe lange blockieren. In PostgreSQL sind bestimmte Operationen mit online‑freundlichen Methoden sicherer; der Kernpunkt ist Timing: führe schwere Operationen bei geringem Traffic aus und messe die Dauer in einer Staging‑Kopie.

Wenn Änderungen besondere Sorgfalt in Produktion brauchen, plane für:

• Einen Zwei‑Schritt‑Rollout (zuerst Schema, dann Code oder umgekehrt), der kompatibel bleibt.
• Backfills, die in Batches laufen.
• Einen klaren Rollback‑Plan (was passiert, wenn das regenerierte Backend zu früh live geht).
• Verifikationsabfragen, die beweisen, dass die Daten den neuen Regeln entsprechen.
• Ein Ticket „alte Felder später entfernen“, sodass Aufräumarbeiten nicht im gleichen Deploy passieren.

Wenn du eine Plattform wie AppMaster verwendest, die Backend‑Code aus dem Data Designer regeneriert, ist die sicherste Denkweise: veröffentliche Änderungen, mit denen alte Daten heute leben können, und verschärfe Regeln erst, nachdem das System sich angepasst hat.

Prinzipien für regenerationssichere Änderungen

Regenerierte Backends sind großartig — bis eine Schemaänderung in Produktion landet und alte Zeilen nicht mehr zur neuen Form passen. Das Ziel regenerationssicherer Schema‑Evolution ist einfach: halte deine App am Laufen, während Datenbank und regenerierter Code sich in kleinen, vorhersehbaren Schritten einholen.

Standard: "Expand, Migrate, Contract"

Behandle jede sinnvolle Änderung als drei Züge. Zuerst das Schema erweitern, sodass alte und neue Codeversionen laufen können. Dann Daten migrieren. Erst danach kontrahieren, indem du alte Spalten, Defaults oder Constraints entfernst.

Praktische Regel: Kombiniere niemals „neue Struktur“ und „zerstörerische Aufräumarbeiten“ im gleichen Deploy.

Unterstütze alte und neue Formen für eine Weile

Nimm an, dass es eine Überlappungsperiode geben wird, in der:

• einige Datensätze die neuen Felder haben, andere nicht
• einige App‑Instanzen alten Code nutzen, andere regenerierten Code
• Hintergrundjobs, Importe oder mobile Clients hinterherhinken

Gestalte die Datenbank so, dass beide Formen gültig sind. Das gilt besonders, wenn eine Plattform dein Backend aus dem neuesten Modell regeneriert (z. B. AppMaster, wenn du den Data Designer aktualisierst und das Go‑Backend regenerierst).

Mach Lesewege kompatibel, bevor du Schreibwege änderst

Sorge zuerst dafür, dass neuer Code alte Daten sicher lesen kann. Wechsle erst danach die Schreibpfade, sodass sie die neue Datenform produzieren.

Beispiel: Wenn du ein einzelnes Feld status in status + status_reason aufteilst, veröffentliche Code, der fehlende status_reason sicher handhabt. Danach schreibe status_reason bei neuen Updates.

Entscheide, wie mit teilweisen und unbekannten Daten umgegangen wird

Wenn du Enums, NOT NULL‑Spalten oder strengere Constraints hinzufügst, entscheide vorab, wie mit fehlenden oder unerwarteten Werten umgegangen wird:

• vorübergehend NULLs erlauben, dann backfill
• einen sicheren Default setzen, der die Bedeutung nicht verfälscht
• einen „unknown“‑Wert behalten, um Leseausfälle zu vermeiden

Das verhindert stille Korruption (falsche Defaults) und harte Fehler (neue Constraints, die alte Zeilen ablehnen).

Habe für jeden Schritt eine Rollback‑Story

Rollback ist während der Expand‑Phase am einfachsten. Falls du zurückrollen musst, sollte alter Code weiterhin gegen das erweiterte Schema laufen. Schreibe auf, was du zurückrollen würdest (nur Code oder Code plus Migration) und vermeide destruktive Änderungen, bis du sicher bist, dass du nicht zurückrudern musst.

Schritt für Schritt: Plane eine Änderung, die Regeneration übersteht

Regenerierte Backends sind gnadenlos: Wenn Schema und generierter Code nicht übereinstimmen, findet Produktion das meist zuerst. Der sicherste Ansatz ist, jede Änderung wie einen kleinen, reversiblen Rollout zu behandeln — auch bei No‑Code‑Tools.

Beginne damit, die Absicht in klarer Sprache aufzuschreiben und wie deine Daten heute aussehen. Nimm 3–5 echte Zeilen aus Produktion (oder ein aktuelles Dump) und notiere die schwierigen Stellen: leere Werte, alte Formate, überraschende Defaults. Das verhindert, dass du ein perfektes neues Feld designst, das reale Daten nicht befriedigen.

Hier eine praktische Reihenfolge, die gut funktioniert, wenn deine Plattform Backend‑Code regeneriert (z. B. AppMaster, das Go‑Services aus dem Data Designer Modell erzeugt):

1. Zuerst erweitern, nicht ersetzen. Füge neue Spalten oder Tabellen additiv hinzu. Mache neue Felder zunächst nullable oder gib sichere Defaults. Wenn du eine neue Beziehung einführst, erlaube den Foreign Key zunächst leer zu sein, bis du ihn befüllt hast.

2. Deploy das erweiterte Schema, ohne etwas zu entfernen. Mache die Datenbankänderung, während alter Code weiter funktioniert. Ziel: alter Code kann weiter die alten Spalten schreiben und die Datenbank akzeptiert das.

3. Backfill per kontrolliertem Job. Fülle neue Felder mit einem Batch‑Prozess, den du überwachen und erneut ausführen kannst. Mach ihn idempotent (zweimal Ausführen darf die Daten nicht beschädigen). Bei großen Tabellen schrittweise vorgehen und loggen, wie viele Zeilen aktualisiert wurden.

4. Zuerst Lesewege umstellen, mit Fallback. Passe den regenerierten Code so an, dass er neue Felder bevorzugt, aber auf alte Felder zurückfällt, wenn neue Daten fehlen. Erst wenn die Lesevorgänge stabil sind, schalte die Schreibvorgänge auf die neuen Felder um.

5. Aufräumen zuletzt. Wenn du Vertrauen hast (und einen Rollback‑Plan), entferne alte Felder und verschärfe Constraints: setze NOT NULL, füge UNIQUE‑Constraints hinzu und erzwinge Foreign Keys.

Konkretes Beispiel: Du willst ein freies Textfeld status durch ein status_id ersetzen, das auf eine Tabelle statuses zeigt. Füge status_id nullable hinzu, fülle es aus den vorhandenen Textwerten, aktualisiere die App, sodass sie status_id liest, aber bei NULL auf status zurückfällt, und lösche dann status und mache status_id required. So bleibt jede Regeneration sicher, weil das Schema in jedem Schritt kompatibel ist.

Praktische Muster, die du wiederverwenden kannst

Wenn dein Backend regeneriert wird, können kleine Schema‑Änderungen APIs, Validierungen und UI‑Formulare beeinflussen. Ziel ist, Änderungen so durchzuführen, dass alte Daten gültig bleiben, während neuer Code ausgerollt wird.

Muster 1: Nicht‑zerstörende Umbenennung

Eine direkte Umbenennung ist riskant, weil alte Datensätze und alter Code oft noch das ursprüngliche Feld erwarten. Sichere Vorgehensweise:

• Füge die neue Spalte hinzu (z. B. customer_phone) und behalte die alte (phone).
• Aktualisiere die Logik auf Dual‑Write: Beim Speichern in beide Felder schreiben.
• Backfill bestehender Zeilen, sodass customer_phone für alle aktuellen Datensätze gefüllt ist.
• Schalte Lesezugriffe auf die neue Spalte um, wenn die Abdeckung hoch ist.
• Entferne die alte Spalte in einem späteren Release.

Das funktioniert gut in Tools wie AppMaster, wo Regeneration Datenmodelle und Endpoints aus dem aktuellen Schema baut. Dual‑Write hält beide Codegenerationen während der Übergangszeit glücklich.

Muster 2: Ein Feld in zwei Felder splitten

Das Aufsplitten von full_name in first_name und last_name ist ähnlich, aber der Backfill ist kniffliger. Behalte full_name so lange, bis der Split vollständig ist.

Praktische Regel: Entferne das ursprüngliche Feld nicht, bis jeder Datensatz entweder backfilled wurde oder einen klaren Fallback hat. Wenn das Parsen fehlschlägt, schreibe den ganzen String z. B. in last_name und markiere den Datensatz zur Nachbearbeitung.

Muster 3: Ein Feld verpflichtend machen

Eine nullable Spalte zu required zu ändern ist ein klassischer Produktionsbrecher. Sichere Reihenfolge: erst backfill, dann erzwingen.

Backfill kann mechanisch sein (Default setzen) oder businessgetrieben (Nutzer auffordern, fehlende Daten zu ergänzen). Erst wenn die Daten komplett sind, NOT NULL setzen und Validierungen anpassen. Wenn dein regenerierter Backendcode automatisch striktere Validierungen hinzufügt, verhindert diese Reihenfolge Überraschungsfehler.

Muster 4: Enum sicher ändern

Enum‑Änderungen brechen, wenn alter Code alte Werte sendet. Während des Übergangs akzeptiere beide Werte. Wenn du z. B. pending durch queued ersetzen willst, halte beide Werte gültig und mappe sie in deiner Logik. Sobald keiner Client mehr den alten Wert sendet, entferne ihn.

Wenn die Änderung in einem Release live gehen muss, verringere das Risiko, indem du den Schadensradius einschränkst:

• Neue Felder hinzufügen, aber alte behalten, auch wenn sie ungenutzt sind.
• Einen Datenbank‑Default verwenden, damit Inserts weiter funktionieren.
• Code tolerant machen: Neu lesen, alt fallbacken.
• Eine temporäre Mapping‑Schicht einbauen (alter Wert rein, neuer Wert speichern).

Diese Muster halten Migrationen vorhersehbar, selbst wenn regenerierter Code sich schnell ändert.

Häufige Fehler, die Überraschungen verursachen

Die größten Überraschungen passieren, wenn Leute Regeneration wie einen magischen Reset‑Knopf behandeln. Regenerierte Backends können deinen Anwendungscode sauber halten, aber deine Produktionsdaten enthalten noch die Form von gestern. Regenerationssichere Schema‑Evolution heißt, für beides zu planen: den neuen Code, der generiert wird, und die alten Datensätze, die noch in Tabellen liegen.

Eine häufige Falle ist zu glauben, die Plattform kümmere sich um Migrationen. Beispiel: In AppMaster kannst du ein Go‑Backend aus dem Data Designer regenerieren, aber die Plattform kann nicht erraten, wie du reale Kundendaten transformiert haben willst. Wenn du ein neues Pflichtfeld hinzufügst, brauchst du immer noch einen Plan, wie bestehende Zeilen einen Wert erhalten.

Eine weitere Überraschung ist, Felder zu früh zu löschen oder umzubenennen. Ein Feld wirkt vielleicht in der Haupt‑UI ungenutzt, wird aber noch von einem Report, einem geplanten Export, einem Webhook‑Handler oder einer Admin‑Ansicht gelesen. Die Änderung sieht im Test sicher aus, bricht aber in Produktion, weil ein vergessener Pfad noch die alte Spalte nutzt.

Fünf Fehler, die oft zu nächtlichen Rollbacks führen:

• Schema ändern und Code regenerieren, aber die Datenmigration, die alte Zeilen gültig macht, nie schreiben oder verifizieren.
• Eine Spalte umbenennen oder löschen, bevor alle Leser und Schreiber aktualisiert und deployed sind.
• Einen großen Backfill starten, ohne die Laufzeit zu prüfen — wie lange dauert er und blockiert er andere Schreibvorgänge?
• Erst ein neues Constraint (NOT NULL, UNIQUE, FK) hinzufügen und dann entdecken, dass Legacy‑Daten es brechen.
• Hintergrundjobs, Exporte und Reports vergessen, die noch alte Felder lesen.

Ein einfaches Szenario: Du nennst phone in mobile_number um, fügst ein NOT NULL hinzu und regenerierst. Die App‑Screens funktionieren, aber ein alter CSV‑Export selektiert noch phone und tausende bestehende Datensätze haben NULL in mobile_number. Die Lösung ist meist ein phasiger Wechsel: Neue Spalte hinzufügen, eine Weile in beide schreiben, sicher backfillen, dann Constraints verschärfen und erst am Ende das alte Feld entfernen.

Kurze Pre‑Deploy‑Checklist für sicherere Migrationen

Wenn dein Backend regeneriert wird, kann sich der Code schnell ändern, aber Produktionsdaten verzeihen keine Überraschungen. Bevor du eine Schemaänderung auslieferst, mach einen kurzen „Kann das sicher fehlschlagen?“‑Check. Das macht regenerationssichere Schema‑Evolution langweilig — genau das, was du willst.

Die 5 Checks, die die meisten Probleme fangen

• Backfill‑Größe und Dauer: Schätze, wie viele bestehende Zeilen aktualisiert werden müssen und wie lange das in Produktion dauert. Ein Backfill, der in einer kleinen DB okay ist, kann auf echten Daten Stunden dauern und die App verlangsamen.
• Locks und Downtime‑Risiko: Identifiziere, ob die Änderung Schreibzugriffe blockieren kann. Manche Operationen (z. B. große Tabellen ändern oder Typkonvertierungen) halten Locks lange. Wenn die Gefahr besteht, plane einen sicheren Rollout (zuerst neue Spalte, später backfill, zuletzt Code‑Switch).
• Alte Codeversion vs. neues Schema: Geh davon aus, dass der alte Backend‑Code kurzzeitig gegen das neue Schema laufen könnte (während Deploy oder Rollback). Wird die vorige Version weiterhin ohne Absturz lesen und schreiben? Wenn nicht, brauchst du eine Zwei‑Schritt‑Veröffentlichung.
• Defaults und NULL‑Verhalten: Entscheide für neue Spalten, was mit bestehenden Datensätzen passiert. Werden sie NULL sein oder brauchst du einen Default? Stell sicher, dass deine Logik fehlende Werte normal behandelt — besonders bei Flags, Statusfeldern und Timestamps.
• Monitoring‑Signale: Wähle die Alarme, die du nach dem Deploy beobachtest: Fehlerrate (API‑Fehler), langsame DB‑Abfragen, Queue/Job‑Fehler und kritische Nutzeraktionen (Checkout, Login, Formular‑Submit). Achte auch auf „stille“ Fehler wie einen Anstieg der Validierungsfehler.

Ein kurzes Beispiel

Wenn du ein neues Pflichtfeld status zur orders‑Tabelle hinzufügst, pushe es nicht sofort als NOT NULL ohne Default. Füge es zuerst nullable mit einem Default für neue Zeilen hinzu, deploye regenerierten Code, der fehlenden Status handhabt, backfille alte Zeilen und verschärfe dann die Constraint.

In AppMaster ist dieses Mindset besonders nützlich, da das Backend dort oft regeneriert wird. Behandle jede Schemaänderung wie ein kleines Release mit einfachem Rollback und deine Migrationen bleiben vorhersehbar.

Beispiel: Eine Live‑App weiterentwickeln, ohne bestehende Datensätze zu brechen

Stell dir ein internes Support‑Tool vor, in dem Agenten Tickets mit einem freien Textfeld priority taggen (Beispiele: high, urgent, HIGH, p1). Du willst auf ein striktes Enum wechseln, damit Reports und Routing‑Regeln nicht raten müssen.

Der sichere Ansatz ist eine Zwei‑Release‑Änderung, die alte Datensätze während der Regeneration gültig hält.

Release 1: Erweitern, in beide schreiben und backfill

Erweitere zuerst das Schema, ohne etwas zu entfernen. Füge ein neues Enum‑Feld priority_enum mit Werten wie low, medium, high, urgent hinzu. Behalte das ursprüngliche priority_text.

Aktualisiere die Logik so, dass neue und bearbeitete Tickets in beide Felder geschrieben werden. In einem No‑Code‑Tool wie AppMaster bedeutet das typischerweise, das Data Designer Modell und den Business Process so zu ändern, dass Eingaben zum Enum gemappt und der Originaltext ebenfalls gespeichert werden.

Dann backfille bestehende Tickets in kleinen Batches. Mappe gängige Textwerte auf das Enum (z. B. p1 und urgent -> urgent, HIGH -> high). Alles Unbekannte kannst du vorübergehend auf medium setzen und später prüfen.

Was Nutzer sehen: Idealerweise ändert sich nichts. Die UI zeigt weiter dieselbe Prioritätsauswahl, aber im Hintergrund befüllst du das neue Enum. Reports können das Enum bereits nutzen, sobald der Backfill läuft.

Release 2: Kontrahieren und alten Pfad entfernen

Wenn du Vertrauen gewonnen hast, schalte Lesezugriffe ausschließlich auf priority_enum, aktualisiere Filter und Dashboards und entferne dann priority_text in einer späteren Migration.

Vor Release 2 validiere mit einer kleinen Stichprobe:

• Nimm 20–50 Tickets aus verschiedenen Teams und Altersgruppen.
• Vergleiche die angezeigte Priorität mit dem gespeicherten Enum‑Wert.
• Prüfe Counts nach Enum‑Wert, um ungewöhnliche Häufungen zu entdecken (z. B. zu viele medium).

Wenn Probleme auftreten, ist das Rollback einfach, weil Release 1 das alte Feld erhalten hat: Rolle Release 1 wieder aus und stell die UI so ein, dass sie priority_text liest, während du Mapping verbesserst und den Backfill erneut ausführst.

Nächste Schritte: Mach Schema‑Evolution zur Routine

Wenn du vorhersehbare Migrationen willst, behandle Schemaänderungen wie ein kleines Projekt, nicht wie einen schnellen Edit. Ziel ist einfach: Jede Änderung sollte leicht zu erklären, einfach zu proben und schwer versehentlich zu zerstören sein.

Ein visuelles Datenmodell hilft, weil es Auswirkungen vor dem Deploy sichtbar macht. Wenn du Tabellen, Relationen und Feldtypen an einem Ort siehst, fallen Dinge auf, die in einem Script leicht übersehen werden — z. B. ein Pflichtfeld ohne sicheren Default oder eine Relation, die alte Datensätze verwaisen lässt. Mach einen kurzen "Wer hängt davon ab?"‑Check: APIs, Screens, Reports und Hintergrundjobs.

Wenn du ein Feld änderst, das bereits genutzt wird, bevorzuge eine kurze Übergangsphase mit duplizierten Feldern. Zum Beispiel: Füge phone_e164 hinzu und behalte phone_raw für ein bis zwei Releases. Lese zuerst aus dem neuen Feld, fall zurück auf das alte, schreibe während der Transition in beide Felder und entferne das alte erst nach vollständigem Backfill.

Umgebungsdisziplin macht gute Absichten zu sicheren Releases. Halte Dev, Staging und Produktion synchron, aber behandle sie nicht als identisch:

• Dev: Prüfe, dass das regenerierte Backend sauber startet und Grundabläufe nach Regeneration funktionieren.
• Staging: Führe den kompletten Migrationsplan gegen produktionsnahe Daten aus und verifiziere wichtige Abfragen, Reports und Importe.
• Produktion: Deploye nur, wenn du einen Rollback‑Plan, klares Monitoring und eine kleine Menge „must pass“ Checks hast.

Mach deinen Migrationsplan zu einem echten Dokument, auch wenn es kurz ist. Enthält: Was ändert sich, in welcher Reihenfolge, wie backfillen, wie verifizieren und wie zurückrollen. Dann führe ihn einmal komplett in einer Testumgebung durch, bevor er Produktion berührt.

Wenn du AppMaster verwendest, nutze den Data Designer, um visuell über das Modell nachzudenken, und lass Regeneration deinen Backend‑Code konsistent mit dem aktualisierten Schema halten. Die Gewohnheit, Migrationen explizit zu machen, sorgt dafür, dass du schnell iterieren kannst — aber jede Änderung hat trotzdem einen geplanten Pfad für bestehende Produktionsdaten.