Vergleich und Auswahl von Datenmigrationssystemen
Das Datenmodell neigt dazu, sich während des Entwicklungsprozesses zu ändern, und irgendwann stimmt es nicht mehr mit der Datenbank überein. Natürlich kann die Datenbank gelöscht werden, und dann erstellt der ORM eine neue Version, die dem Modell entspricht, aber dieser Vorgang führt zum Verlust vorhandener Daten. Die Funktion des Migrationssystems besteht also darin, es infolge einer Schemaänderung mit dem Datenmodell in der Anwendung zu synchronisieren, ohne dass vorhandene Daten verloren gehen.
In diesem Artikel möchten wir verschiedene Tools zur Verwaltung von Datenbankmigrationen betrachten. Wir hoffen, dass dieser Testbericht für Entwickler hilfreich sein wird, die vor einer ähnlichen Entscheidung stehen.
Aufgabe
Unser Unternehmen entwickelt derzeit aktiv die nächste Generation des Produkts – Docs Security Suite (DSS). Der Serverteil ist in .Net Core geschrieben und der Entity Framework Core wird jeweils als DBMS verwendet. Beim Entwerfen einer Anwendung verwenden wir den Code First-Ansatz.
Das Anwendungsdomänenmodell wird von mehreren Entwicklern gleichzeitig erstellt – jeder ist für seinen eigenen logischen Teil des Systems verantwortlich.
Die vorherige DSS-Generation nutzte das klassische Entity Framework Migrations (EF 6) als Migrationsmanagementsystem. Allerdings häuften sich einige Beschwerden gegen ihn, von denen die wichtigste darin bestand, dass es EF an einem vernünftigen Ansatz zur Lösung von Versionskonflikten mangele. Diese Tatsache stört uns immer noch, wenn wir im Rahmen des Supports Fehler beheben, sodass wir uns entschieden haben, alternative Optionen in Betracht zu ziehen.
Als Ergebnis der Diskussion wurden folgende Anforderungen an das Migrationsmanagementsystem formuliert:
- Unterstützung für verschiedene DBMS. Obligatorisch MS SQL Server, PostgreSQL, Oracle, es ist jedoch möglicherweise möglich, andere zu verwenden
- Arbeiten mit ORM Ursprünglich sollte EF Core zum Einsatz kommen, doch in der Entwurfsphase standen andere ORMs bereit, in Betracht gezogen zu werden
- Automatische Generierung von Migrationen. Angesichts der Entwicklung von Code First möchte ich die Notwendigkeit vermeiden, Migrationen „mit Stiften zu malen“.
- Versionskonflikte. In einer verteilten Entwicklungsumgebung kann es beim Zusammenführen von EF Core zu Konflikten kommen. Dies stellt ein erhebliches Problem dar, da verschiedene Teile der Anwendung von verschiedenen Entwicklern erstellt werden und Sie daher jeweils viel Zeit aufwenden müssen
- Entwickelte Dokumentation und Support. Hier bedarf es unserer Meinung nach keiner Erklärung.
- Frei. Das Kriterium ist bedingt, da wir keine sehr teuren oder teuren Systeme, aber ideal im Komfort, berücksichtigen wollten
Als Ergebnis einer kleinen Studie wurden die folgenden Optionen gefunden und als wünschenswert erachtet:
- EF Core-Migrationen
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Fließender Migrant
Und jetzt noch ein bisschen mehr
Dies war natürlich die erste und wichtigste Wahlmöglichkeit. Ein natives Instrument, das ohne Tamburintanz sofort funktioniert. Eine große Menge an offizieller und nicht offizieller Dokumentation, Einfachheit usw. Die gegenüber dem klassischen EF erhobenen Behauptungen gelten jedoch auch für EF Core.
Daher werden die Vorteile von EF Core hervorgehoben:
- Microsoft-Support, Dokumentation, auch auf Russisch, eine riesige Community
- Automatische Generierung von Migrationen basierend auf CodeFirst
- Im Vergleich zu EF 6 speichert EF Core keinen Snapshot der Datenbank mehr. Bei der Arbeit mit EF Core in Code First ist die Bereitstellung der Datenbank nicht mehr erforderlich
- Da wir von Code First ausgehen, ist es möglich, eine Migration zu allen erforderlichen Datenzugriffsanbietern durchzuführen
- Die Anbieter unterstützen PostgreSQL, Oracle usw. usw. und sogar MS SQL Server
Und auch Nachteile:
- Die Konfliktlösung bleibt gleich. Es ist notwendig, eine Abfolge von Migrationen zu erstellen und Datenbank-Snapshots zu aktualisieren
- Abhängigkeit von Modellen, auf deren Grundlage Migrationen generiert werden
DbUp
DbUp ist eine .NET-Bibliothek, die von NuGet installiert wird und dabei hilft, Änderungen an SQL Server zu übertragen. Es verfolgt, welche Änderungsskripte bereits ausgeführt wurden, und führt diejenigen aus, die zur Aktualisierung der Datenbank erforderlich sind. Die Bibliothek ist aus einem Open-Source-Blogging-Engine-Projekt auf ASP.NET hervorgegangen und steht unter der MIT-Lizenz. Der Code befindet sich auf GitHub. Migrationen werden mit T-SQL beschrieben.
Welche Vorteile gibt es hier:
- Unterstützung für eine große Anzahl von DBMS (MS SQL Server, PstgreSQL, MySQL)
- Da die Skripte in T-SQL geschrieben sind, sehen sie recht einfach aus.
- Konflikte werden auch mit SQL gelöst
Und die Nachteile:
- Bei all der Vielfalt der unterstützten DBMS gehört Oracle nicht dazu
- Interagiert nicht mit ORM
- Das Schreiben von Skripten in T-SQL mit „Handles“ ist nicht unser Ziel
- Dokumentation und Community sind mittelmäßig, obwohl sie für das Schreiben von SQL-Skripten möglicherweise nicht erforderlich sind.
RoundhouseE
Dieses Migrationsverwaltungstool, das wie das vorherige unter der Apache 2.0-Lizenz vertrieben wird, läuft auf der T-SQL-Migrations-Engine. Anscheinend konzentrierten sich die Entwickler auf die Lösung technischer Probleme im Hinblick auf die Unterstützung des DBMS und nicht auf die Schaffung eines komfortablen Entwicklungsprozesses.
Profis:
- Unterstützt das erforderliche DBMS (einschließlich Oracle)
Nachteile:
- Oracle (sowie Access, was für uns irrelevant ist) wird auf .NET Core nicht unterstützt, sondern nur auf .NET Full Framework
- Funktioniert nicht mit ORM
- Noch weniger Dokumentation als das vorherige Tool
- Noch einmal: Migrationen werden durch Skripte geschrieben
ThinkingHome.Migrator
Tool zur versionierten Migration des Datenbankschemas auf die .NET Core-Plattform, vertrieben unter der MIT-Lizenz.
Profis:
- Maßgeschneidert für .NET Core
- Eine verzweigte Migrationssequenz wurde implementiert
- Migrationsprotokollierung implementiert
Nachteile:
- Das letzte Update war vor einem Jahr. Offenbar wird das Projekt nicht unterstützt
- Wird von Oracle nicht unterstützt (im Artikel heißt es, dass dies am Fehlen einer stabilen Implementierung für .NET Core liegt – das ist aber schon ein Jahr her)
- Fehlende automatische Generierung von Migrationen
Im Allgemeinen sieht das Projekt vielversprechend aus, insbesondere wenn es sich entwickelt, aber wir mussten hier und jetzt eine Entscheidung treffen.
Fließender Migrant
Das beliebteste Migrationstool mit einer großen Fangemeinde. Verteilt unter der Apache 2.0-Lizenz. Wie in der Beschreibung angegeben, handelt es sich um ein Migrationsframework für .NET, ähnlich wie Ruby on Rails Migrations. Änderungen des Datenbankschemas werden in C#-Klassen beschrieben.
Hier gibt es Pluspunkte:
- Unterstützung für das erforderliche DBMS
- .NET Core-Unterstützung
- Große entwickelte Gemeinschaft
- Migrationskonflikte werden nacheinander gelöst – die Migrationsreihenfolge wird angegeben. Wenn außerdem beim Zusammenführen des Codes ein Konflikt um eine Entität auftritt, wird dieser auf die gleiche Weise gelöst wie im Rest des Codes.
- Es gibt Profile, die nach einer erfolgreichen Migration ausgeführt werden. Und sie können Servicefunktionen tragen. Das letzte Update war vor einem Monat, das heißt, das Projekt lebt
Was die Nachteile betrifft, dann hier:
- Fehlende automatische Generierung von Migrationen
- Fehlende Kommunikation mit EF-Modellen
- Keine DB-Snapshots
Was war unsere Wahl?
Die heißeste Debatte drehte sich um zwei Parameter – die automatische Generierung von Migrationen und eine vernünftige Konfliktlösung. Andere Faktoren machten uns viel weniger Angst. Aufgrund der Ergebnisse der Diskussion entschied sich das Team daher für den Einsatz von Fluent Migrator im neuen Projekt. Denn die Lösung von Konflikten wird in Zukunft noch viel mehr Vorteile mit sich bringen.
Befund
Natürlich gibt es keine perfekten Werkzeuge. Also mussten wir unsere „Wunschliste“ priorisieren, um eine Wahl zu treffen. Für andere Teams und andere Aufgaben können jedoch andere Faktoren ausschlaggebend sein. Wir hoffen, dass dieser Artikel Ihnen bei Ihrer Wahl hilft.
Source: habr.com