Vergleich und Auswahl von Datenmigrationssystemen

Vergleich und Auswahl von Datenmigrationssystemen

Das Datenmodell im Entwicklungsprozess hat die Eigenschaft, sich zu ändern, und irgendwann entspricht es nicht mehr der Datenbank. Natürlich kann die Datenbank gelöscht werden, und dann erstellt ORM eine neue Version, die dem Modell entspricht, aber ein solches Verfahren führt zum Verlust vorhandener Daten. Die Funktion des Migrationssystems besteht daher darin, sicherzustellen, dass das Schema infolge einer Änderung mit dem Datenmodell in der Anwendung synchronisiert wird, ohne dass vorhandene Daten verloren gehen.

In diesem Artikel möchten wir verschiedene Tools zum Verwalten von Datenbankmigrationen betrachten. Wir hoffen, dass diese Bewertung für Entwickler nützlich ist, die vor dieser Wahl stehen.

Herausforderung

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 entsprechend als DBMS verwendet. Beim Entwerfen der Anwendung verwenden wir den Code First-Ansatz.

Das Domänenmodell der Anwendung wird von mehreren Entwicklern gleichzeitig erstellt - jeder ist für seinen eigenen logischen Teil des Systems verantwortlich.

In der vorherigen Generation von DSS wurde das klassische Entity Framework Migrations (EF 6) als Migrationsmanagementsystem verwendet. Es haben sich jedoch einige Behauptungen gegen sie angesammelt, von denen die Hauptursache darin bestand, dass EF keinen vernünftigen Ansatz zur Lösung von Versionskonflikten aufweist. Diese Tatsache stört uns immer noch, wenn wir Fehler im Rahmen des Supports beheben. Daher wurde beschlossen, alternative Optionen in Betracht zu ziehen.

Als Ergebnis der Diskussion wurden die folgenden Anforderungen an das Migrationsmanagementsystem gebildet:

1. Unterstützung für verschiedene DBMS. Obligatorisch MS SQL Server, PostgreSQL, Oracle, aber Sie können möglicherweise andere verwenden
2. Arbeiten Sie mit ORM. Ursprünglich war die Verwendung von EF Core vorgesehen, aber in der Entwurfsphase waren andere ORMs bereit, dies in Betracht zu ziehen
3. Autogeneration von Migrationen. Angesichts der Entwicklung von Code First möchte ich vermeiden, dass Migrationen „mit Stiften malen“ müssen
4. Versionskonflikte. In einer verteilten Entwicklungsumgebung mit Zusammenführung kann EF Core in Konflikten abstürzen. Dies wird zu einem erheblichen Problem, da verschiedene Teile der Anwendung von verschiedenen Entwicklern erstellt werden, sodass Sie für jeden Teil viel Zeit aufwenden müssen
5. Erweiterte Dokumentation und Support. Hier scheint uns keine Erklärung erforderlich zu sein
6. Kostenlos. Das bedingte Kriterium, da nicht sehr teure Systeme oder teuer, aber ideal in der Bequemlichkeit, waren wir auch bereit zu berücksichtigen

Als Ergebnis einer kleinen Studie wurden die folgenden Optionen gefunden und als wünschenswert angesehen:

1. Ef Kernmigrationen
2. Dbup
3. RoundhousE
4. ThinkingHome.Migrator
5. Fließender Migrator

Und jetzt noch ein bisschen mehr

EntityFramework-Kernmigrationen

Dies war natürlich die erste und wichtigste Option für die Wahl. Ein natives Werkzeug, das sofort funktioniert, ohne mit einem Tamburin zu tanzen. Eine große Menge an Dokumentation, offiziell und nicht sehr, Einfachheit usw. Die dem klassischen EF vorgelegten Ansprüche sind jedoch für den EF Core sehr relevant.

Somit werden die Vorteile für EF Core hervorgehoben:

• Microsoft-Support, Dokumentation, auch in russischer Sprache, eine riesige Community
• CodeFirst-basierte automatische Migration
• Im Vergleich zu EF 6 wird der Datenbank-Snapshot nicht mehr in EF Core gespeichert. Wenn Sie mit EF Core in Code First arbeiten, müssen Sie keine Datenbank mehr bereitstellen
• Da wir von Code First aus tanzen, ist es möglich, eine Migration zu allen erforderlichen Datenzugriffsanbietern durchzuführen
• In Bezug auf Anbieter - PostgreSQL, Oracle usw. usw. usw. und sogar - wird MS SQL Server unterstützt

Sowie Nachteile:

• Die Konfliktlösung blieb auf dem gleichen Niveau. Es ist erforderlich, eine Folge von Migrationen zu erstellen und Datenbankabbilder zu aktualisieren
• Abhängigkeit von Modellen, auf deren Grundlage Migrationen generiert werden

Dbup


dbup.imtqy.com

DbUp ist eine .NET-Bibliothek, die von NuGet installiert wird und dabei hilft, Änderungen an SQL Server vorzunehmen. Es verfolgt, welche Änderungsskripte bereits ausgeführt wurden, und startet diejenigen, die zum Aktualisieren der Datenbank erforderlich sind. Die Bibliothek ist aus dem Open Source-Blog-Engine-Projekt ASP.NET hervorgegangen und steht unter der MIT-Lizenz. Der Code befindet sich auf GitHub. Migrationen werden mit T-SQL beschrieben.

Was sind die Vorteile:

• Unterstützung für eine große Anzahl von DBMS (MS SQL Server, PstgreSQL, MySQL)
• Da Skripte in T-SQL geschrieben sind, sehen sie ziemlich einfach aus
• Konflikte werden auch mit SQL gelöst

Ein Nachteil:

• Bei der Vielzahl der unterstützten DBMS gehört Oracle nicht dazu.
• Interagiert nicht mit ORM
• Das Schreiben von T-SQL-Skripten mit Stiften ist nicht das Ziel
• Dokumentation und Community sind mittelmäßig, obwohl sie beim Schreiben von SQL-Skripten möglicherweise nicht benötigt werden.

RoundhousE


github.com/chucknorris/roundhouse

Dieses Migrationsverwaltungstool, das wie das vorherige unter der Apache 2.0-Lizenz vertrieben wird, wird auf der T-SQL-Migrations-Engine ausgeführt. Anscheinend konzentrierten sich die Entwickler darauf, technische Probleme im Zusammenhang mit der DBMS-Unterstützung zu lösen, anstatt einen komfortablen Entwicklungsprozess zu erstellen.

Vorteile:

• Unterstützt das erforderliche DBMS (einschließlich Oracle)

Nachteile:

• Oracle (sowie Access, das für uns irrelevant ist) wird unter .NET Core nicht unterstützt, sondern nur unter .NET Full Framework
• Funktioniert nicht mit ORM
• Es gibt noch weniger Dokumentation als das vorherige Tool
• Wieder - Migrationen werden in Skripten geschrieben

ThinkingHome.Migrator



Ein Tool für die versionierte Migration eines Datenbankschemas für die .NET Core-Plattform, das unter der MIT-Lizenz vertrieben wird. Der Entwickler selbst hat vor fast einem Jahr über die neueste Version geschrieben .

Vorteile:

• Unter .NET Core geschärft
• Implementierte Verzweigungssequenz von Migrationen
• Migrationsprotokollierung implementiert

Nachteile:

• Letztes Update - vor einem Jahr. Anscheinend wird das Projekt nicht unterstützt.
• Wird von Oracle nicht unterstützt (der Artikel besagt, dass dies auf das Fehlen einer stabilen Implementierung für .NET Core zurückzuführen ist - dies ist jedoch ein Jahr her).
• Fehlende automatische Generierung von Migrationen

Im Allgemeinen sieht das Projekt vielversprechend aus, besonders wenn es sich entwickeln würde, aber wir mussten hier und jetzt eine Entscheidung treffen.

Fließender Migrator


github.com/fluentmigrator/fluentmigrator

Das beliebteste Migrationstool mit einer großen Anzahl von Fans. Unter der Apache 2.0-Lizenz vertrieben. Wie in der Beschreibung angegeben, handelt es sich um eine Migrationsplattform für .NET, ähnlich wie bei Ruby on Rails-Migrationen. Änderungen am Datenbankschema werden in Klassen in C # beschrieben.

Es gibt Pluspunkte:

• Unterstützung für das notwendige DBMS
• .NET Core-Unterstützung
• Große entwickelte Gemeinschaft
• Migrationskonflikte werden nacheinander gelöst - die Ausführungsreihenfolge wird für Migrationen angegeben. Wenn beim Zusammenführen von Code ein Konflikt um eine Entität besteht, wird die Lösung auf dieselbe Weise wie im Rest des Codes ausgeführt
• Es gibt Profile, die nach einer erfolgreichen Migration ausgeführt werden. Und sie können Servicefunktionen ausführen. Das letzte Update war vor einem Monat, das heißt, das Projekt lebt

Was die Nachteile betrifft, hier:

• Fehlende automatische Generierung von Migrationen
• Keine Verbindung mit EF-Modellen
• Keine Datenbank-Snapshots

Was war unsere Wahl?

Die hitzigste Debatte drehte sich um zwei Parameter - die automatische Generierung von Migrationen und eine vernünftige Konfliktlösung. Andere Faktoren hatten viel weniger Angst. Als Ergebnis der Diskussion entschied sich das Team, Fluent Migrator in dem neuen Projekt zu verwenden. Für die Lösung von Konflikten in der Zukunft werden viel mehr Vorteile bringen.

Schlussfolgerungen

Natürlich gibt es keine perfekten Werkzeuge. Also mussten wir unsere „Wunschliste“ für eine Auswahl priorisieren. Andere Faktoren können jedoch für andere Teams und andere Aufgaben entscheidend sein. Wir hoffen, dieser Artikel hilft Ihnen bei der Auswahl.