Je mets en place une WebApi en .NET Core 2.0. J’utiliserai Entity Framework Core comme ORM. L’ensemble de l’application sera déployé en tant que conteneur Docker. Ce qui me perturbe un peu, c’est la manière de gérer les migrations de base de données dans ce cas. Je parle de l’environnement de PRODUCTION. Voici ce que j’ai réussi à trouver :
On lance simplement Database.Migrate() au démarrage de l’application en oubliant le reste du monde - hmm d’une certaine manière je n’aime pas ça
Database.Migrate() piloté par un paramètre en ligne de commande (exécuter le conteneur Docker une fois avec un paramètre spécifié pour migrer la base de données)
Se connecter au conteneur de l’application et exécuter dotnet ef database update
Générer du SQL pur et simple basé sur les migrations et l’exécuter depuis un outil de gestion de base de données. Semble vieux jeu mais valide. Ce que je déteste, c’est de devoir exécuter les scripts moi-même.
Préparer un conteneur de base de données qui contiendrait déjà les scripts générés depuis le code ci-dessus, et qui les exécuterait automatiquement.
D’autres suggestions ? Ou quelle est la meilleure solution, la plus appropriée ?
À mon avis, c’est votre premier point (Database.Migrate() au démarrage) qui correspond le mieux à notre cas d’utilisation. Donc pour moi, c’est actuellement la façon préférée de procéder.
Nous avons quelques configurations supplémentaires dans le processus de démarrage :
Conteneur Docker uniquement en local (pour l’environnement de développement et les tests bien sûr)
Projet de démarrage séparé qui exécute la partie Database.Migrate() (car nous avons plus d’un projet avec sa propre base de données)
Projet supplémentaire avec le site web API proprement dit
Environnement de production avec Azure SQL server (publié et déployé via le pipeline Azure DevOps)
Les migrations sont créées dans leur propre projet via dotnet ef …
dotnet ef migrations add "votre nom de migration" --startup-project "chemin vers votre API" --context "nom du contexte de base de données"
Important :
vous devez d’abord changer le répertoire de travail vers le projet de migration afin d’utiliser un autre projet de démarrage mais de générer les fichiers de migration dans le “projet de migration”
Dans notre cas, cela fonctionne bien avec différentes API ayant chacune leur propre base de données en coulisses.
