Comparaison et sélection des systèmes de migration de données
Le modèle de données en cours de développement a tendance à changer, et à un certain moment, il ne correspond plus à la base de données. Bien sûr, il est possible de supprimer la BD, et alors l'ORM créera une nouvelle version qui sera conforme au modèle, mais cette procédure entraînera la perte des données existantes. Ainsi, la fonction du système de migration se résume à synchroniser le schéma avec le modèle de données dans l'application suite à une modification, sans perte des données existantes.
Dans cet article, nous aimerions examiner divers outils pour la gestion des migrations de bases de données. Nous espérons que cet aperçu sera utile aux développeurs confrontés à un choix similaire.
La tâche
Notre entreprise développe actuellement la prochaine génération de produit – Docs Security Suite (DSS). La partie serveur est écrite en .Net Core, et comme SGBD, nous utilisons évidemment Entity Framework Core. Lors de la conception de l'application, nous adoptons une approche Code First.
Le modèle de domaine de l'application est créé par plusieurs développeurs simultanément – chacun est responsable de sa propre partie logique du système.
Dans la génération précédente de DSS, le système de gestion des migrations utilisait le classique Entity Framework Migrations (EF 6). Cependant, certaines critiques se sont accumulées à son égard, la principale étant l'absence d'une approche raisonnable pour résoudre les conflits de versions. Ce fait nous contrarie encore lors de la correction de bogues dans le cadre du support, c'est pourquoi nous avons décidé d'explorer des alternatives.
À l'issue des discussions, les exigences suivantes pour le système de gestion des migrations ont été établies :
- Support de différents SGBD. MS SQL Server, PostgreSQL, Oracle sont obligatoires, mais l'utilisation d'autres est potentiellement possible.
- Travail avec ORM. L'utilisation d'EF Core était initialement prévue, mais lors de la phase de conception, d'autres ORM ont également été envisagées.
- Autogénération des migrations. Étant donné que nous développons en Code First, nous souhaitons éviter de "rédiger manuellement" les migrations.
- Conflits de versions. Dans un contexte de développement distribué, lors du merge, EF Core peut échouer à cause des conflits. Cela devient un problème considérable, car différentes parties de l'application sont créées par différents développeurs, ce qui entraîne une perte de temps significative à chaque fois.
- Documentation et support avancés. Ici, nous pensons qu'aucune explication n'est nécessaire.
- Gratuité. Ce critère est subjectif, car nous étions également prêts à envisager des systèmes peu coûteux ou coûteux mais très pratiques.
À la suite d'une petite étude, les options suivantes ont été identifiées et jugées dignes d'être examinées :
- Migraciones EF Core
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
Et maintenant, un peu plus de détails
Évidemment, c'était la première et principale option à choisir. Un outil natif, fonctionnant en direct sans aucun bricolage. Une grande quantité de documentation, officielle et autre, simplicité, etc. Cependant, les critiques adressées à l’EF classique restent tout à fait pertinentes pour EF Core.
Ainsi, pour EF Core, on souligne les avantages :
- Support Microsoft, documentation en plusieurs langues, y compris en russe, énorme communauté.
- Génération automatique des migrations sur la base de CodeFirst.
- Comparé à EF 6, EF Core ne conserve plus de snapshot de la base de données. Avec EF Core en Code First, il n'est désormais pas nécessaire de déployer la base de données.
- Comme nous partons de Code First, il est possible d’avoir une migration pour tous les fournisseurs d'accès aux données requis.
- Concernant les fournisseurs, il supporte à la fois PostgreSQL, Oracle, etc., et même – MS SQL Server 😊.
Et en ce qui concerne les inconvénients :
- La résolution des conflits est restée au même niveau. Il est nécessaire de structurer la séquence des migrations et de mettre à jour les snapshots de la base de données.
- Dépendance des modèles sur la base desquels les migrations ont été générées.
DbUp
DbUp est une bibliothèque .NET, installable via NuGet, qui aide à appliquer des modifications sur SQL Server. Elle suit quels scripts de modification ont déjà été exécutés et exécute ceux qui sont nécessaires pour mettre à jour la base de données. La bibliothèque a évolué à partir d'un projet de moteur de blog open source sous ASP.NET et existe sous licence MIT, avec le code disponible sur GitHub. Les migrations sont décrites à l'aide de T-SQL.
Quels sont les avantages ici :
- Support d'un grand nombre de SGBD (MS SQL Server, PostgreSQL, MySQL).
- Comme les scripts sont écrits en T-SQL, ils sont assez simples.
- Les conflits sont également résolus à l'aide de SQL.
Et les inconvénients :
- Malgré la grande variété de SGBD supportés, Oracle n'en fait pas partie.
- N'interagit pas avec l'ORM.
- Écriture des scripts en T-SQL à la main – ce n'est pas ce vers quoi nous tendons.
- La documentation et la communauté laissent à désirer, bien qu'elles ne soient peut-être pas nécessaires dans le cadre de l'écriture de scripts SQL.
RoundhousE
Cet outil de gestion des migrations, distribué sous licence Apache 2.0, fonctionne également sur le moteur T-SQL des migrations. Il semble que les développeurs aient mis l'accent sur la résolution des problèmes techniques liés au support des SGBD plutôt que sur la création d'un processus de développement confortable.
Avantages :
- Supporte les SGBD nécessaires (y compris Oracle)
Inconvénients :
- Oracle (ainsi qu'Access, qui n'est plus d'actualité pour nous) n'est pas supporté sur .NET Core, seulement sur le .NET Full Framework.
- Ne fonctionne pas avec l'ORM.
- Il y a encore moins de documentation que pour l'outil précédent.
- Encore une fois, les migrations sont écrites en scripts.
ThinkingHome.Migrator
Outil de migration de version du schéma de base de données pour la plateforme .NET Core, distribué sous licence MIT. .
Avantages :
- Conçu pour .NET Core.
- Une séquence de migrations ramifiée a été implémentée.
- Le logging des migrations a été réalisé.
Inconvénients :
- Dernière mise à jour il y a un an. Le projet ne semble pas être maintenu.
- Oracle n'est pas supporté (l'article indique que c'est dû à l'absence d'une implémentation stable pour .NET Core - mais cela date d'un an).
- Absence d'auto-génération des migrations.
Dans l'ensemble, le projet semble prometteur, surtout s'il se développait, mais nous devions prendre une décision ici et maintenant.
Fluent Migrator
L'outil de migration le plus populaire, avec une grande armée de fans. Distribué sous licence Apache 2.0. Comme indiqué dans la description, c'est une plateforme de migration pour .NET, similaire aux Migrations de Ruby on Rails. Les modifications du schéma de la BDD sont décrites dans des classes en C#.
Voici les avantages :
- Support des SGBD nécessaires.
- Support de .NET Core.
- Grande communauté active.
- Les conflits de migrations sont résolus de manière séquentielle – pour les migrations, l'ordre d'exécution est précisé. De plus, s'il y a un conflit autour d'une entité, la résolution lors du merge du code se déroule comme dans le reste du code.
- Il existe des profils qui s'exécutent après une migration réussie. Ils peuvent aussi avoir des fonctions de service. La dernière mise à jour a eu lieu il y a un mois, donc le projet est actif.
En ce qui concerne les inconvénients, il y a :
- Absence d'auto-génération des migrations.
- Absence de lien avec les modèles EF.
- Pas de snapshots de BDD.
Quelle a été notre décision ?
Les débats les plus passionnés ont eu lieu autour de deux paramètres : l'autogénération des migrations et une solution raisonnable pour les conflits. Les autres facteurs étaient beaucoup moins inquiétants. En fin de compte, suite aux discussions, l'équipe a décidé d'utiliser Fluent Migrator pour le nouveau projet. En effet, la résolution des conflits apportera à long terme de nombreux avantages.
Conclusions
Bien sûr, il n'existe pas d'outils parfaits. Nous avons donc dû établir des priorités dans nos « souhaits » pour faire notre choix. Cependant, d'autres équipes et d'autres projets pourraient être influencés par d'autres facteurs. Nous espérons que cet article vous aidera à faire le bon choix.
Source : habr.com
