Est-il correct de mettre à jour une base de données de production avec des migrations EF?
Selon ce billet de blog la plupart des entreprises utilisant EF Migrations ne sont pas censées mettre à jour le schéma de base de données des bases de données de production avec les migrations EF. À la place, l'auteur de l'article de blog recommande d'utiliser des scripts de mise à jour de schéma dans le cadre du processus de déploiement.
J'utilise des scripts de mise à jour de schéma depuis quelques années maintenant et pendant qu'ils fonctionnent, je prévoyais d'utiliser à la place les migrations EF pour les raisons suivantes:
- Déploiement plus rapide, moins de temps d'arrêt
- Une procédure de déploiement plus simple
- Migration des données existantes beaucoup plus facile qu'il ne serait possible avec T-SQL
- Une syntaxe plus compréhensible des modifications en attente d'application (classe DbMigration avec une syntaxe C # propre vs un script de migration T-SQL maladroit dans un environnement traditionnel).
- Il existe un chemin de rétrogradation facile et rapide vers l'ancien schéma de base de données si le déploiement de la nouvelle version du logiciel échoue
Une raison pour laquelle je peux penser que cela interdirait l'utilisation d'EF pour migrer une base de données de production serait si le schéma de base de données n'était modifié que par les administrateurs de base de données par opposition aux développeurs. Cependant, je suis à la fois DBA et développeur, donc cela n'a pas d'importance dans mon cas.
Alors, quels sont les risques de mettre à jour une base de données de production à l'aide d'EF?
Edit: je voudrais ajouter que, comme l'a déjà suggéré solomon8718, je tire toujours une nouvelle copie de la base de données de production sur mon serveur de transfert et teste les migrations EF à appliquer sur le serveur de transfert avant de les appliquer à un serveur de production. IMO, cela est essentiel pour toute mise à jour de schéma vers un système de production, que j'utilise des migrations EF ou non.
Eh bien, je vais essayer de répondre de toute façon. Je dirais que non, il n'y a aucune raison de ne pas utiliser Code First Migrations en production. Après tout, quel est l'intérêt de ce système facile à utiliser si vous ne pouvez pas tout faire?
Les plus gros problèmes que je vois avec ce sont tous les problèmes que vous pouvez avoir avec n'importe quel système, que vous avez déjà noté. Tant que toute l'équipe (DBA incluse le cas échéant) est à ses côtés, je pense qu'autoriser EF à gérer le schéma via les migrations est moins complexe, et donc moins sujet aux erreurs que la gestion traditionnelle basée sur des scripts. Je prendrais toujours une sauvegarde avant d'effectuer une migration sur un système de production, mais vous le feriez de toute façon.
Rien ne dit non plus qu'un DBA ne peut pas effectuer une migration à partir de Visual Studio. L'accès peut toujours être verrouillé avec des privilèges au niveau de la base de données, et il/elle peut revoir la migration (dans un format d'exportation SQL utile en utilisant -Script, Si vous le souhaitez) avant d'effectuer l'opération réelle. Ensuite, ils sont toujours sous contrôle, mais vous pouvez utiliser des migrations en premier code. Enfer, ils pourraient même finir par l'aimer!
Mise à jour: depuis que les SPROC et les TVF ont été mis en place, nous traitons également ceux des migrations, bien qu'ils soient en fait effectués avec des instructions SQL directes à l'aide d'un appel DbMigration.Sql() dans Up(), et l'inverse dans la Down() (Vous pouvez également utiliser CreateStoredProcedure et DropStoredProcedure pour les SPROC simples, mais je pense que vous devez encore définir le corps lui-même en SQL). Je suppose que vous pourriez dire que c'est une mise en garde; il n'y a pas encore de moyen pour qu'une base de données complète et complète soit écrite uniquement en C #. Cependant, vous pouvez utilisez des migrations qui incluent des scripts SQL pour gérer l'intégralité du schéma. Un avantage que nous avons trouvé de ce processus est que vous pouvez utiliser le fichier de configuration C # pour les noms d'objets de schéma (différents noms de serveur pour la production vs dev par exemple) avec un simple String.Format, Combiné avec la transformation XML pour les fichiers de configuration se.
Oui, il y a de bonnes raisons pas à utiliser un système automatisé tel que Code First Migrations pour effectuer la production des modifications de la base de données. Mais comme toujours, il y a des exceptions aux règles.
L'une des raisons évoquées serait les autorisations d'accès, qui seraient directement liées aux règles de gestion des changements et aux politiques de sécurité de votre organisation.
Une autre raison serait votre niveau de confiance dans l'outil de migration lui-même. Sommes-nous sûrs que l'outil ne contient pas de bogue? Que se passe-t-il si l'outil échoue à mi-parcours? Êtes-vous certain de disposer de sauvegardes à jour et d'un processus de restauration si nécessaire?
Les scripts de modification peuvent exécuter des scripts inattendus ou inefficaces. J'ai rencontré des cas où le sql généré a copié les données dans une table temporaire, supprimé la table d'origine, puis recréé la table d'origine pour des choses comme l'ajout d'une nouvelle colonne si vous modifiez accidentellement (ou délibérément) l'ordre dans lequel la colonne apparaît, ou lorsque vous renommez la table. Si des millions d'enregistrements sont impliqués, cela peut entraîner de graves problèmes de performances.
Ma recommandation:
En supposant que vous disposiez d'une base de données intermédiaire qui reflète votre schéma de production, utilisez l'outil Migrations pour générer ses scripts de modification sur ce système. Nous restaurons généralement notre base de données de scène à partir d'une nouvelle copie de production avant de l'exécuter. Nous examinons ensuite les scripts de modification manuellement pour vérifier les problèmes. Après cela, nous exécutons les scripts sur notre base de données de scène pour nous assurer qu'elle s'exécute correctement et que toutes les modifications attendues ont eu lieu. Maintenant, nous sommes sûrs que les scripts peuvent être exécutés en production en toute sécurité et effectuer les modifications attendues. Ce processus réglerait les trois problèmes que j'ai énumérés ci-dessus.
Une autre mise en garde que j'ai trouvée: si vous avez plusieurs sites Web utilisant le même contexte de données, vous devez vous assurer qu'ils sont tous mis à jour en même temps. Sinon, il pourrait y avoir un combat constant de mise à jour/rétrogradation de la base de données entre les sites Web. A part ça, ça a bien marché pour moi.
EDIT: Ma propre perspective un an après avoir commencé à utiliser EF Migrations dans la production:
EF Migrations est en fait assez cool, même pour une utilisation en production, à condition que vous
- Testez les migrations sur un système intermédiaire. Je teste toutes les migrations en migrant de haut en bas sur mon serveur CI avant d'exécuter des tests d'intégration.
- Ne déclenchez pas les migrations automatiquement, mais avec un fichier de commandes lancé par un administrateur. C'est essentiellement la même chose que l'exécution de SQL pour une migration manuellement dans SSMS.
Je l'utilise en production pour quelques projets. Une fois que vous aurez compris, je pense que ça va.
Pendant le développement, vous pouvez conserver les migrations automatiques mais à la fin, vous pouvez vous connecter à la base de données en direct directement à partir de la console du gestionnaire de packages et générer une migration. Il vous donnera une migration pour toutes les modifications.
Mais toujours toujours toujours utiliser le -script option avec update-database et lancez le SQL vous-même.
Je conseillerais également de ne pas utiliser l'option de mise à jour de la base de données du déploiement Web. De cette façon, il n'y a aucun moyen de savoir dans quelle mesure la migration a déjà été déclenchée par erreur. J'ai rencontré des problèmes à plusieurs reprises. Il est donc préférable d'obtenir le SQL et de le déclencher manuellement.