Comparaison et sélection de systèmes de migration de données
Le modèle de données a tendance à changer au cours du processus de développement 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 l'ORM créera une nouvelle version qui correspondra au modèle, mais cette procédure entraînera la perte de données existantes. Ainsi, la fonction du système de migration est de s'assurer que, suite à un changement de schéma, il est synchronisé avec le modèle de données dans l'application sans perdre les données existantes.
Dans cet article, nous aimerions examiner divers outils de gestion des migrations de bases de données. Nous espérons que cette revue sera utile aux développeurs confrontés à un choix similaire.
Tâche
Notre société développe actuellement activement la prochaine génération du produit - Docs Security Suite (DSS). La partie serveur est écrite en .Net Core et Entity Framework Core est utilisé comme SGBD, respectivement. Lors de la conception d'une application, nous utilisons l'approche Code First.
Le modèle de domaine d'application est créé par plusieurs développeurs en même temps - chacun est responsable de sa propre partie logique du système.
La génération précédente de DSS utilisait les migrations Entity Framework classiques (EF 6) comme système de gestion des migrations. Cependant, certaines plaintes se sont accumulées contre lui, dont la principale était que EF n'avait pas une approche sensée 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 des migrations ont été définies :
- Prise en charge de divers SGBD. Obligatoire MS SQL Server, PostgreSQL, Oracle, mais il est potentiellement possible d'en utiliser d'autres
- Travailler avec ORM Initialement, EF Core devait être utilisé, mais au stade de la conception, d'autres ORM étaient prêts à être pris en compte
- Génération automatique des migrations. Compte tenu du développement de Code First, j'aimerais éviter d'avoir à "peindre avec des stylos" les migrations
- Conflits de versions. Dans un environnement de développement distribué, lors de la fusion, EF Core peut tomber sur des 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 sur chacune
- Documentation et support développés. Ici, nous semble-t-il, aucune explication n'est nécessaire.
- Gratuit. Le critère est conditionnel, puisque des systèmes pas très chers ou coûteux, mais idéaux en commodité, nous étions également prêts à envisager
À la suite d'une petite étude, les options suivantes ont été trouvées et considérées comme souhaitables pour examen :
- Migrations de base EF
- DBup
- RoundhouseE
- ThinkingHome.Migrateur
- Migrateur Courant
Et maintenant un peu plus
Naturellement, c'était la première et principale option de choix. Un instrument natif qui fonctionne hors de la boîte sans aucune danse de tambourin. Une grande quantité de documentation, officielle et non, la simplicité, etc. Cependant, les affirmations faites contre l'EF classique sont également tout à fait pertinentes pour EF Core.
Ainsi, les avantages sont mis en évidence pour EF Core :
- Support Microsoft, documentation, y compris en russe, une énorme communauté
- Auto-génération de migrations basées sur CodeFirst
- Par rapport à EF 6, EF Core ne stocke plus d'instantané de la base de données. Le déploiement de la base de données n'est plus nécessaire lorsque vous travaillez avec EF Core dans Code First
- Puisque nous dansons depuis Code First, il est possible d'effectuer une migration vers tous les fournisseurs d'accès aux données requis
- Quant aux fournisseurs, il prend en charge PostgreSQL, Oracle, etc., etc., et même MS SQL Server
Et aussi des inconvénients :
- La résolution des conflits reste la même. Il est nécessaire de construire une séquence de migrations et de mettre à jour les instantanés de la base de données
- Dépendance aux modèles sur la base desquels les migrations sont générées
DbUp
DbUp est une bibliothèque .NET qui est installée par NuGet et permet de pousser les modifications vers SQL Server. Il garde une trace des scripts de changement qui ont déjà été exécutés et exécute ceux nécessaires pour mettre à jour la base de données. La bibliothèque est née d'un projet de moteur de blog open source sur 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 ici :
- 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 avec SQL
Et les inconvénients :
- Avec toute la variété de SGBD pris en charge, Oracle n'en fait pas partie
- N'interagit pas avec ORM
- Écrire des scripts en T-SQL avec des "handles" n'est pas ce que nous recherchions
- La documentation et la communauté sont moyennes, bien qu'en termes d'écriture de scripts SQL, elles ne soient peut-être pas nécessaires.
RoundhouseE
Cet outil de gestion des migrations, distribué sous licence Apache 2.0, comme le précédent, tourne sur le moteur de migrations T-SQL. Apparemment, les développeurs se sont concentrés sur la résolution de problèmes techniques en termes de prise en charge du SGBD, plutôt que sur la création d'un processus de développement confortable.
Avantages:
- Prend en charge les SGBD requis (y compris Oracle)
Inconvénients:
- Oracle (ainsi qu'Access, qui n'est pas pertinent pour nous) n'est pas pris en charge sur .NET Core, uniquement sur .NET Full Framework
- Ne fonctionne pas avec ORM
- Encore moins de documentation que l'outil précédent
- Encore une fois - les migrations sont écrites par des scripts
ThinkingHome.Migrateur
Outil de migration versionnée du schéma de base de données vers la plateforme .NET Core, distribué sous licence MIT. .
Avantages:
- Conçu pour .NET Core
- Mise en œuvre d'une séquence de branchement de migrations
- Implémentation de la journalisation de la migration
Inconvénients:
- La dernière mise à jour date d'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 c'était il y a un an)
- Auto-génération manquante des migrations
En général, le projet semble prometteur, surtout s'il se développe, mais nous devions prendre une décision ici et maintenant.
Migrateur Courant
L'outil de migration le plus populaire avec une large base de fans. Distribué sous la licence Apache 2.0. Comme indiqué dans la description, est un framework de migration pour .NET, similaire à Ruby on Rails Migrations. Les modifications de schéma de base de données sont décrites dans les classes C#.
Il y a des avantages ici :
- Prise en charge du SGBD requis
- Prise en charge de .NET Core
- Grande communauté développée
- Les conflits de migration sont résolus séquentiellement - l'ordre de migration est spécifié. De plus, si un conflit survient autour d'une entité, lors de la fusion du code, il est résolu de la même manière que dans le reste du code.
- Certains profils s'exécutent après une migration réussie. Et ils peuvent effectuer des fonctions de service. La dernière mise à jour date d'il y a un mois, c'est-à-dire que le projet vit
Quant aux inconvénients, alors ici:
- Auto-génération manquante des migrations
- Communication manquante avec les modèles EF
- Aucun instantané de base de données
Quel a été notre choix ?
Le débat le plus chaud a tourné autour de deux paramètres - l'auto-génération des migrations et la résolution saine des conflits. D'autres facteurs effrayaient beaucoup moins. En conséquence, sur la base des résultats 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 un plus grand nombre d'avantages.
résultats
Bien sûr, il n'y a pas d'outils parfaits. Nous avons donc dû prioriser notre "Wishlist" pour faire un choix. Cependant, pour d'autres équipes et d'autres tâches, d'autres facteurs peuvent être décisifs. Nous espérons que cet article vous aidera à faire votre choix.
Source: habr.com