À mon sens la migration est la fonctionnalité ultime d’Entity Framework. Par moment, il m’arrive cependant de la détester…

Vous avez peut-être déjà vécu l’un de ces moments : On reprend un projet qui beaucoup évolué par rapport au plan initial et l’on souhaite explorer le modèle de donnée. Là on découvre qu’il y a plus de 100 fichiers dans le dossier Migrations alors que l’application en est tout au plus à sa 10ème release…

Forcément quand l’application créé une nouvelle base, c’est un peu lent.

Ce rapport dix migrations pour une Release est totalement disproportionné. Alors que s’est-il passé ?

Si vous explorer votre TFS ou votre Git, vous allez certainement constater l’un des points suivants :

• Il y a eu trop de micro-check-in sur le modèle de données.
• Lors d’un même de check-in il y a plusieurs migrations.

Parfois, il peut effectivement être utile de faire des micro-check-in (je suis d’ailleurs partisan de ceux-ci le reste du temps). Mais si cela implique la multiplication des migrations, c’est une mauvaise idée.

Mais pourquoi cela impliquerait la multiplication des migrations ? Et pourquoi un développeur remonterait plusieurs migrations en un seul check-in ?

En discutant avec plusieurs équipes, je me suis rendu compte qu’il y avait une grosse méprise sur l’utilité des migrations :

• Dès que le modèle de données change, une migration est ajoutée au projet.
• Durant les tests, on peut avoir besoin de faire plusieurs tests pour préparer une release. Une migration est produite avant chaque test

L’intérêt de la migration, est de faire évoluer une base de données existante sans perde ses données tout en restant en mesure de monter ou descendre de version son modèle. Donc si on ne déploie pas l’application en production, il n’est pas d’intérêt à produire une migration.

Alors, pourquoi font-ils ainsi ?

La réponse est malheureusement simple : ils ne savent pas que l’on peut utiliser plusieurs fois de suite la commande add-migration avec le même nom de migration. Finalement, une seule migration sera produite.

Pourtant, quand on ajoute une migration, le message affiché dans la console est très explicite :

PM> add-migration MigrationName
Scaffolding migration 'MigrationName'.
The Designer Code for this migration file includes a snapshot of your current Code First model. This snapshot is used to calculate the changes to your model when you scaffold the next migration. If you make additional changes to your model that you want to include in this migration, then you can re-scaffold it by running 'Add-Migration MigrationName' again.

Moralité

Prenez le temps de lire ce qui s’affiche dans la console. Vous éviterez de polluer vos projets ;)

Pour rappel, lors des tests, on peut aussi supprimer des migration via la commande Remove-Migration. Alors, pourquoi se priver ?