Comparaison et sélection de systèmes de migration de données

Comparaison et sélection de systèmes de migration de données

Le modèle de données dans le processus de développement a la propriété de changer et à un moment donné, il cesse de correspondre à la base de données. Bien sûr, la base de données peut être supprimée, puis ORM créera une nouvelle version qui correspondra au modèle, mais une telle procédure entraînera la perte de données existantes. Ainsi, la fonction du système de migration est de garantir que, suite à la modification du schéma, le synchroniser avec le modèle de données dans l'application sans perdre les données existantes.

Dans cet article, nous aimerions considérer différents outils pour gérer les migrations de bases de données. Nous espérons que cette revue sera utile aux développeurs confrontés à ce choix.

Défi

Notre société développe actuellement activement la prochaine génération du produit - Docs Security Suite (DSS). La partie serveur est écrite sur .Net Core et Entity Framework Core est respectivement utilisée comme SGBD. Lors de la conception de l'application, nous utilisons l'approche Code First.

Le modèle de domaine de l'application est créé par plusieurs développeurs en même temps - chacun est responsable de sa propre partie logique du système.

Dans la génération précédente de DSS, le classique Entity Framework Migrations (EF 6) était utilisé comme système de gestion des migrations. Cependant, certaines réclamations se sont accumulées contre elle, la principale étant que EF n'a pas une approche saine pour résoudre les conflits de version. Ce fait nous dérange toujours lors de la correction de bogues dans le cadre du support, il a donc été décidé d'envisager des options alternatives.

À la suite de la discussion, les exigences suivantes pour le système de gestion de la migration ont été formées:

1. Prise en charge de divers SGBD. Obligatoire MS SQL Server, PostgreSQL, Oracle, mais vous pouvez potentiellement utiliser d'autres
2. Travaillez avec ORM. Initialement, l'utilisation d'EF Core était supposée, mais au stade de la conception, d'autres ORM étaient prêts à envisager
3. Autogénération des migrations. Étant donné le développement de Code First, je voudrais éviter d'avoir à migrer avec des stylos
4. Conflits de version. Dans un environnement de développement distribué avec fusion, EF Core peut se bloquer dans les conflits. Cela devient un problème important, car différentes parties de l'application sont créées par différents développeurs, vous devez donc passer beaucoup de temps pour chacune
5. Documentation et support avancés. Ici, il nous semble, aucune explication n'est nécessaire
6. Gratuit. Le critère conditionnel, puisque les systèmes ne sont pas très chers ou chers, mais idéal dans la commodité, nous étions également prêts à considérer

À la suite d'une petite étude, les options suivantes ont été trouvées et jugées souhaitables:

1. Migrations de cœur EF
2. Dbup
3. RoundhousE
4. ThinkingHome.Migrator
5. Migrateur courant

Et maintenant un peu plus

Migrations de base EntityFramework

Naturellement, c'était la première et principale option de choix. Un outil natif qui fonctionne hors de la boîte sans danser avec un tambourin. Une grande quantité de documentation, officielle et pas très, simplicité, etc. Cependant, les revendications présentées à l'EF classique sont tout à fait pertinentes pour l'EF Core.

Ainsi, les avantages d'EF Core sont mis en évidence:

• Support Microsoft, documentation, y compris en russe, une énorme communauté
• Migration automatique basée sur CodeFirst
• Par rapport à EF 6, l'instantané de la base de données n'est plus stocké dans EF Core. Lorsque vous travaillez avec EF Core dans Code First, vous n'avez plus à déployer de base de données
• Puisque nous dansons sur Code First - il est possible d'effectuer une migration vers tous les fournisseurs d'accès aux données requis
• Concernant les fournisseurs - PostgreSQL, Oracle, etc., etc., etc., et même - MS SQL Server sont pris en charge

Ainsi que les inconvénients:

• La résolution des conflits est restée au même niveau. Il est nécessaire de construire une séquence de migrations et de mettre à jour les images de base de données
• Dépendance à l'égard des modèles sur la base desquels les migrations sont générées

Dbup


dbup.imtqy.com

DbUp est une bibliothèque .NET qui est installée par NuGet et aide à apporter des modifications à SQL Server. Il garde la trace des scripts de changement qui ont déjà été exécutés et lance ceux qui sont nécessaires pour mettre à jour la base de données. La bibliothèque est née du projet de moteur de blog open source ASP.NET et existe sous la licence MIT, et le code est sur GitHub. Les migrations sont décrites à l'aide de T-SQL.

Quels sont les avantages:

• Prise en charge d'un grand nombre de SGBD (MS SQL Server, PstgreSQL, MySQL)
• Comme les scripts sont écrits en T-SQL, ils semblent assez simples
• Les conflits sont également résolus à l'aide de SQL

Un contre:

• Avec toute la variété des SGBD pris en charge, Oracle ne fait pas partie d'eux.
• N'interagit pas avec ORM
• L'écriture de scripts T-SQL avec des stylets n'est pas ce que nous visions
• La documentation et la communauté sont telles quelles, bien qu'elles ne soient peut-être pas nécessaires dans le contexte de l'écriture de scripts SQL.

RoundhousE


github.com/chucknorris/roundhouse

Cet outil de gestion de la migration, distribué sous la licence Apache 2.0, comme le précédent, s'exécute sur le moteur de migration T-SQL. Apparemment, les développeurs se sont concentrés sur la résolution de problèmes techniques concernant la prise en charge du SGBD, plutôt que sur la création d'un processus de développement confortable.

Avantages:

• Prend en charge le SGBD nécessaire (y compris Oracle)

Inconvénients:

• Oracle (ainsi qu'Access non pertinent pour nous) n'est pas pris en charge sur .NET Core, uniquement sur .NET Full Framework
• Ne fonctionne pas avec ORM
• Il y a encore moins de documentation que l'outil précédent
• Encore une fois - les migrations sont écrites dans des scripts

ThinkingHome.Migrator



Un outil pour la migration versionnée d'un schéma de base de données pour la plate-forme .NET Core, distribué sous la licence MIT. Le développeur lui-même a écrit il y a près d'un an sur la dernière version .

Avantages:

• Aiguisé sous .NET Core
• Implémentation de la séquence de branchement des migrations
• Journalisation de la migration implémentée

Inconvénients:

• Dernière mise à jour - il y a un an. Apparemment, le projet n'est pas pris en charge.
• Non pris en charge par Oracle (l'article indique que cela est dû à l'absence d'une implémentation stable pour .NET Core - mais il y a un an)
• Génération automatique des migrations manquante

En général, le projet semble prometteur, surtout s'il se développerait, mais nous devions prendre une décision ici et maintenant.

Migrateur courant


github.com/fluentmigrator/fluentmigrator

L'outil de migration le plus populaire avec une grande armée de fans. Distribué sous la licence Apache 2.0. Comme indiqué dans la description, il s'agit d'une plate-forme de migration pour .NET, similaire à Ruby on Rails Migrations. Les modifications apportées au schéma de base de données sont décrites dans les classes en C #.

Il y a des avantages:

• Prise en charge du SGBD nécessaire
• Prise en charge de .NET Core
• Grande communauté développée
• Les conflits de migrations sont résolus de manière séquentielle - l'ordre d'exécution est indiqué pour les migrations. De plus, en cas de conflit autour d'une entité, lors de la fusion de code, sa solution s'effectue de la même manière que dans le reste du code
• Il existe des profils qui s'exécutent après une migration réussie. Et ils peuvent transporter des fonctions de service. La dernière mise à jour remonte à un mois, c'est-à-dire que le projet vit

Quant aux inconvénients, voici:

• Génération automatique des migrations manquante
• Pas de connexion avec les modèles EF
• Aucun instantané de base de données

Quel a été notre choix?

Le débat le plus houleux a tourné autour de deux paramètres: l'auto-génération des migrations et la résolution saine des conflits. D'autres facteurs ont fait beaucoup moins peur. En conséquence, à la suite de la discussion, l'équipe a décidé d'utiliser Fluent Migrator dans le nouveau projet. Car la résolution des conflits à l'avenir apportera beaucoup plus d'avantages.

Conclusions

Bien sûr, il n'y a pas d'outils parfaits. Nous avons donc dû prioriser notre «liste de souhaits» pour un choix. Cependant, d'autres facteurs peuvent être décisifs pour d'autres équipes et d'autres tâches. Nous espérons que cet article vous aidera à faire un choix.