DB-Migrationen in Legacy-Systemen ohne ORM: Struktur und Praxis

Datenbank-Migrationssystem für Legacy-Projekte ohne ORM

In Legacy-Systemen ohne ORM erfordert die Verwaltung von DDL/DML-Skript-Migrationen strenge Kontrolle. Dieser Ansatz organisiert ein Repository und Status-Tabellen für die konsistente Anwendung von Änderungen in Test- und Produktionsumgebungen. Er gewährleistet Nachverfolgbarkeit, Datenintegrität und vorhersehbare Deployments in relationalen Datenbanken mit ACID-Konformität.

Die Methode reduziert Boilerplate-Code in Skripten, automatisiert Validierung und Logging. Skripte unterteilen sich in vier Typen: Initialisierung, Baseline, versioniert und wiederholbar. Jeder Typ folgt spezifischen Regeln, um Duplikate zu vermeiden und Versionsmonotonie zu wahren.

Git-Repository-Struktur

Skripte werden nach Typ gruppiert und in fester Reihenfolge angewendet:

• Umgebungsinitialisierung — einmalig ausführen, um Benutzer, Rollen, Datenbanken und Schemata zu erstellen. Umgebungsspezifisch (Test/Prod), ausgeführt via psql.
• Baseline — einmalig auf leerem Schema ausführen, um die anfängliche Produktionsversion und Steuertabellen zu etablieren.
• Versioniert — sequentiell nach aufsteigenden Integer-Versionen anwenden, nur einmal, innerhalb einer Transaktion, die Zeitstempel und Benutzer loggt.
• Wiederholbar — anwenden, wenn SHA256 geändert hat oder kein Eintrag existiert, nach versionierten Skripten, für Views/Prozeduren/Trigger ohne Datenänderungen.

Objekttypen:

• Initialisierung: Benutzer, Rollen, Datenbanken, Schemata.
• Baseline: Tabellen, Daten, Views, Prozeduren, Trigger.
• Versioniert: Schema-Änderungen, Datenmigrationen.
• Wiederholbar: Views, Prozeduren, Trigger.

Diese Struktur ist von Flyway inspiriert, aber auf manuelle Prozesse ohne externe Tools zugeschnitten.

Status-Tabellen im Schema

Jedes Schema erhält Diensttabellen zur Verfolgung:

• dbmigration_versions (version_id, is_baseline, created_at, created_by, created_from) — verfolgt Baseline- und versionierte Skript-Historie.
• dbmigration_repeatable (sha256sum, relative_path, created_at, created_by, created_from) — verfolgt wiederholbare Skripte, ermöglicht Neuanwendung bei Änderungen.

Diese Tabellen erzwingen Prüfungen vor Skriptausführung: Ein Skript läuft nur, wenn kein Eintrag existiert oder der Checksum geändert hat. Logs erfassen Benutzer und Zeitstempel für vollständige Audit-Trails.

Entwicklung-Deployments

In CI/CD (GitLab-Pipelines) Branch mit Änderungen klonen, dann für jedes Schema:

$ git clone <url with database schema changes>
$ USER_PASSWORD=topsecret123 dbmigration.py update --host <host> --port <port> --dbname <db> --user <user_name> schema1 ./db/schema1
$ USER_PASSWORD=topsecret123 dbmigration.py update --host <host> --port <port> --dbname <db> --user <user_name> schema2 ./db/schema2

Dies wendet ausstehende Skripte automatisch an, während Daten erhalten bleiben.

Produktionsprozess

Unterstützt Hot-Deployments ohne Ausfallzeiten. Vorab in UAT mit Smoke-Tests getestet.

Schritte:

• Archiv entpacken: tar xzvf system-x.y.z.tar.gz.
• Ins Schema-Verzeichnis: cd system-x.y.z/schema1.
• Migrationsskript generieren: USER_PASSWORD=topsecret123 dbmigration.py verify --host <host> --port <port> --dbname <db> --user <user_name> --build-update-script ./schema1_migrate.sql schema1 ./db/schema1.
• schema1_migrate.sql auf Breaking Changes prüfen.
• Anwenden: PGPASSWORD=topsecret123 psql -h <host> -p <port> -U <user> -d <database> -v schema_name=<schema1> -f "schema1_migrate.sql".

Für jedes Schema wiederholen. Verify-Modus zeigt Änderungen ohne Anwendung an.

Wichtige Praktiken

• Fix forward: Neue Migrationen für Fehlerkorrekturen statt Rollbacks, um Daten zu erhalten.
• Nicht-breaking Changes: Tabellen/Spalten zuerst hinzufügen, nach Release entfernen, wenn ungenutzt. Ermöglicht Multi-Version-Koexistenz in einer DB.
• Schema-Ebene-Tracking: Versionen pro Schema, nicht pro Datenbank.
• Vorprüfungen: Skripte zur Überprüfung generieren.
• Datenerhalt: Inkrementelle Updates vermeiden Drop/Recreate.

Wichtige Erkenntnisse

• Automatisiertes Tracking eliminiert manuelle Boilerplate und Skriptfehler.
• Monotone Versionen mit Transaktionen sorgen für konsistente Zustände.
• Hotfix-Support über Versionen (Prod/UAT/Dev) via versionierter Skripte.
• Vollständige Audit-Trails aus Tabellen: Wer/Wann/Was angewendet.
• Funktioniert mit jedem ACID-konformen RDBMS.

— Editorial Team