Quels sont les dangers liés à l'utilisation des migrations EF (ou de tout cadre d'auto-migration) en production?

Question

J'envisage d'utiliser les migrations Entity Framework 4.3 dans un site de production. Ce qui suit est ma préoccupation:

Si la migration échoue pour une raison quelconque, je souhaite que toutes les déclarations annulé et le site placé dans un état indisponible pour qu'aucun utilisateur ne puisse utiliser le site pendant que j'essaye de résoudre le problème. La seule chose est que je ne peux pas revenir à l'exécution manuelle des scripts sur la base de données depuis les fichiers de migration sont compilés dans l'assembly. Je pourrais garder une trace de les fichiers de migration et les fichiers de script sql séparément, mais à ce stade, pourquoi utiliser migrations du tout.

Au travail, les fichiers de script sont stockés dans un dossier SQL (que personne ne peut parcourir) sur le site. Les fichiers de script précédemment exécutés sont enregistrés dans la base de données. Lorsque de nouveaux fichiers de script apparaissent dans le dossier (et ne sont pas dans la base de données), si un utilisateur est un administrateur, ils seront redirigés vers un portail de base de données, sinon un site est arrêté pour maintenance. Si nous essayons et échouons d'exécuter des scripts à partir du portail, nous récupérons les nouveaux scripts et essayons de les exécuter manuellement dans Express Studio. Cela a fonctionné pendant plus d'une décennie. J'explore uniquement les migrations pour voir si un meilleur moyen est arrivé. Ça ne ressemble pas à ça. S'il vous plaît laissez-moi savoir s'il existe un meilleur moyen et si ce n'est pas des migrations, de quoi s'agit-il?

Answer 1

Je n'utiliserais certainement pas de migrations automatiques dans un environnement de production. En fait, je suis trop un maniaque du contrôle pour utiliser des migrations automatiques. Je préfère les migrations basées sur le code pour m'assurer que toutes les bases de données (personnel des développeurs, environnement de test, production) ont subi exactement la même séquence de mise à jour.

À l'aide de migrations basées sur du code où chaque étape de migration obtient un nom, un script de migration distinct peut être généré pour être utilisé lors de la levée des environnements de test et de production. De préférence, il doit être exécuté sur une copie de la base de données à valider avant de s'exécuter sur l'environnement réel de production.

Ajouté plus tard

Pour empêcher les migrations EF de faire quoi que ce soit d'automatique, une stratégie d'initialisation personnalisée peut être utilisée. Voir mon blog ou Deploying EF Code First Apps to Production Database Question de Stack Overflow.