Vergleich und Auswahl von Datenmigration-Systemen
Das Datenmodell im Entwicklungsprozess ändert sich und stimmt irgendwann nicht mehr mit der Datenbank überein. Natürlich kann die Datenbank gelöscht werden, woraufhin das ORM eine neue Version erstellt, die mit dem Modell übereinstimmt, aber dieses Verfahren führt zum Verlust von vorhandenen Daten. Daher besteht die Funktion des Migrationssystems darin, das Schema nach Änderungen mit dem Datenmodell der Anwendung zu synchronisieren, ohne bestehende Daten zu verlieren.
In diesem Artikel möchten wir verschiedene Tools zur Verwaltung von Datenbankmigrationen betrachten. Wir hoffen, dieser Überblick wird Entwicklern hilfreich sein, die vor einer ähnlichen Entscheidung stehen.
Ziel
In unserem Unternehmen wird derzeit aktiv an der nächsten Generation des Produkts – der Docs Security Suite (DSS) – gearbeitet. Der Serverteil wird mit .Net Core entwickelt, und als DBMS verwenden wir entsprechend Entity Framework Core. Bei der Anwendungsplanung nutzen wir den Ansatz Code First.
Das Domänenmodell der Anwendung wird von mehreren Entwicklern gleichzeitig erstellt – jeder ist für seinen logischen Teil des Systems verantwortlich.
Im vorherigen DSS-Generation wurde das klassische Entity Framework Migrations (EF 6) als Migrationsmanagementsystem verwendet. Allerdings gab es einige Bedenken, insbesondere, dass EF keinen brauchbaren Ansatz zur Konfliktlösung bei Versionen bietet. Diese Tatsache bereitet uns bis heute Probleme beim Bugfixing im Rahmen des Supports, weshalb beschlossen wurde, alternative Optionen zu prüfen.
Im Ergebnis der Diskussionen wurden folgende Anforderungen an das Migrationsmanagementsystem formuliert:
- Unterstützung verschiedener DBMS. MS SQL Server, PostgreSQL, Oracle sind erforderlich, aber potenziell ist auch die Nutzung anderer Systeme möglich.
- Kompatibilität mit ORM. Ursprünglich war die Verwendung von EF Core vorgesehen, jedoch waren wir in der Planungsphase bereit, auch andere ORMs in Betracht zu ziehen.
- Automatische Generierung von Migrationen. Angesichts der Entwicklung mit Code First möchten wir die Notwendigkeit vermeiden, Migrationen manuell zu erstellen.
- Versionskonflikte. In einer verteilten Entwicklungsumgebung kann es beim Mergen von EF Core zu Konflikten kommen. Dies stellt ein erhebliches Problem dar, da verschiedene Teile der Anwendung von unterschiedlichen Entwicklern erstellt werden, was bedeutet, dass viel Zeit für jeden Konflikt aufgewendet werden muss.
- Umfassende Dokumentation und Unterstützung. Hierbei benötigen wir, unserer Meinung nach, keine weiteren Erklärungen.
- Kostenlosigkeit. Dieses Kriterium ist relativ, da wir auch bereit sind, verschiedene Systeme in Betracht zu ziehen, die entweder nicht sehr teuer oder teuer, aber in der Bedienung perfekt sind.
Nach einer kurzen Recherche wurden folgende Optionen als wünschenswert für die Prüfung identifiziert:
- EF Core Migrations
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
Und jetzt etwas mehr Details
Natürlich war dies die erste und wesentliche Wahl. Ein natives Werkzeug, das sofort ohne viel Aufwand funktioniert. Eine Fülle von Dokumentation, sowohl offizielle als auch inoffizielle, Einfachheit usw. Allerdings sind die bei klassischem EF geäußerten Kritikpunkte auch für EF Core durchaus relevant.
Daher ergeben sich für EF Core folgende Vorteile:
- Unterstützung durch Microsoft, Dokumentation, einschließlich auf Russisch, eine riesige Community.
- Automatische Migrationserstellung basierend auf CodeFirst
- Im Vergleich zu EF 6 wird in EF Core jetzt kein Datenbank-Snapshot gespeichert. Bei der Arbeit mit EF Core ist es nun nicht mehr notwendig, die Datenbank im Code First zu erstellen.
- Da wir von Code First ausgehen, besteht die Möglichkeit, eine Migration für alle benötigten Datenzugriffsprovider zu führen.
- Bezüglich der Provider werden sowohl PostgreSQL als auch Oracle unterstützt, und sogar – MS SQL Server 😊
Und hier sind die Nachteile:
- Die Konfliktlösung bleibt auf dem gleichen Niveau. Es ist notwendig, die Reihenfolge der Migrationen festzulegen und die Datenbank-Snapshots zu aktualisieren.
- Abhängigkeit von den Modellen, auf dessen Grundlage die Migrationen erstellt wurden.
DbUp
DbUp ist eine .NET-Bibliothek, die über NuGet installiert wird und hilft, Änderungen auf SQL Server anzuwenden. Sie verfolgt, welche Änderungs-Skripte bereits ausgeführt wurden, und führt die notwendigen aus, um die Datenbank zu aktualisieren. Die Bibliothek entstand aus einem Open-Source-Projekt für einen Blog-Engine auf ASP.NET und existiert unter der MIT-Lizenz, der Code befindet sich auf GitHub. Migrationen werden mit T-SQL beschrieben.
Welche Vorteile gibt es:
- Unterstützung einer Vielzahl von DBMS (MS SQL Server, PostgreSQL, MySQL)
- Da die Skripte in T-SQL geschrieben werden, sind sie recht einfach.
- Konflikte werden ebenfalls mit SQL gelöst
Die Nachteile sind:
- Trotz der Vielzahl unterstützter DBMS gehört Oracle nicht dazu
- Interagiert nicht mit ORM
- Das Schreiben von Skripten in T-SQL von Hand ist nicht das, was wir uns erhofft hatten
- Die Dokumentation und die Community sind eher durchschnittlich. In der SQL-Skript-Erstellung könnten sie jedoch möglicherweise weniger wichtig sein.
RoundhousE
Dieses Migrationsmanagement-Tool, das unter der Apache 2.0-Lizenz veröffentlicht wird, funktioniert wie das vorherige auf der T-SQL-Migrations-Engine. Anscheinend legten die Entwickler den Fokus darauf, technische Probleme hinsichtlich der DBMS-Unterstützung zu lösen, anstatt einen komfortablen Entwicklungsprozess zu schaffen.
Vorteile:
- Unterstützt erforderliche DBMS (einschließlich Oracle)
Nachteile:
- Oracle (und auch das für uns irrelevante Access) wird nicht von .NET Core unterstützt, nur vom .NET Full Framework
- Funktioniert nicht mit ORM
- Die Dokumentation ist sogar noch spärlicher als bei dem vorherigen Tool
- Wieder einmal – Migrationen werden durch Skripte geschrieben
ThinkingHome.Migrator
Ein Tool zur versionierten Migration von Datenbankschemata für die .NET Core-Plattform, das unter der MIT-Lizenz veröffentlicht wird. .
Vorteile:
- Für .NET Core optimiert
- Ein verzweigter Migrationsverlauf wurde implementiert
- Migration Logging Implementiert
Nachteile:
- Letzte Aktualisierung vor einem Jahr. Anscheinend wird das Projekt nicht mehr unterstützt.
- Oracle wird nicht unterstützt (im Artikel steht, dass dies an der fehlenden stabilen Umsetzung für .NET Core liegt – was vor einem Jahr war).
- Automatische Migrationserstellung fehlt.
Insgesamt sieht das Projekt vielversprechend aus, insbesondere wenn es weiterentwickelt würde, aber wir mussten hier und jetzt eine Entscheidung treffen.
Fluent Migrator
Das beliebteste Migrationstool mit einer großen Anhängerschaft. Es wird unter der Lizenz Apache 2.0 verbreitet. Wie in der Beschreibung angegeben, ist es eine Migrationsplattform für .NET, ähnlich den Ruby on Rails Migrations. Datenbankschemas werden in C#-Klassen beschrieben.
Hier sind einige Vorteile:
- Unterstützung der erforderlichen DBMS
- Unterstützung von .NET Core
- Große, aktive Community
- Migrationskonflikte werden sequenziell gelöst – Migrationen haben eine Ausführungsreihenfolge. Wenn ein Konflikt um eine Entität auftritt, wird dessen Lösung beim Merging des Codes ebenso behandelt wie im restlichen Code.
- Es gibt Profile, die nach erfolgreichem Abschluss der Migration ausgeführt werden. Sie können Dienstleistungsfunktionen beinhalten. Das letzte Update fand vor einem Monat statt, was bedeutet, dass das Projekt aktiv ist.
Was die Nachteile betrifft, so sind hier:
- Automatische Migrationserstellung fehlt.
- Fehlende Verbindung zu den EF-Modellen
- Keine Datenbankschnappschüsse
Wie war unsere Wahl?
Die heißesten Debatten drehten sich um zwei Parameter – die automatische Generierung von Migrationen und sinnvolle Lösungen für Konflikte. Andere Faktoren waren weitaus weniger besorgniserregend. Letztendlich entschied das Team nach Diskussionen, im neuen Projekt Fluent Migrator zu verwenden. Denn die Lösung von Konflikten wird langfristig deutlich mehr Vorteile bringen.
Fazit
Natürlich gibt es keine perfekten Werkzeuge. Auch wir mussten bei der Auswahl Prioritäten setzen. Für andere Teams und verschiedene Aufgaben können jedoch andere Faktoren entscheidend sein. Wir hoffen, dass dieser Artikel Ihnen bei Ihrer Entscheidung hilft.
Quelle: habr.com
