Introduction
Entity Framework est une technologie établie dans le domaine des ORM et dans le monde du .NET.
Note : Object Relational Mapping, qui fait le lien entre la persistance des données et le code plus « métier »
Il y a plusieurs méthodes pour établir le modèle de données l’une d’entre une étant le « code first » c’est-à-dire que c’est notre code qui va piloter l’évolution du schéma SQL. (ce qui simplifie énormément de choses et qui vous permet de vous concentrer sur le code métier et non les implémentation techniques)
Lorsque l’on choisit cette approche il existe deux possibilités pour mettre à jour le schéma et lancer les migrations SQL :
La console nuget ou DNX, c’est-à-dire qu’un développeur devra s’en charger lors du déploiement sur un environnement
L’auto migration : c’est-à-dire que c’est Entity Framework qui va s’en charger automatiquement lorsqu’il détecte qu’il y a une mise à jour au démarrage de l’application. Si cette approche est séduisante pour les petits projets, elle apporte un certain nombre d’inconvénients : dégradation des performances au démarrage de l’application, moins de maitrise de « quand » va se faire la mise à jour
Par que nous sommes des fainéants , parce que nous voulons éviter les erreurs, les oublis, faire gagner du temps à tout le monde, nous allons automatiser ce processus de façon maitrisée.
Les exemples que vous verrez sont faits sur une base de projet DNX, mais pour des projets .NET « classiques » c’est très similaire, simplement les commandes qui changent un peu.
Note : cet article prend pour acquis que vous avez suivi quelque chose de similaire à ça pour votre projet contenant le dbcontext
https://docs.efproject.net/en/latest/platforms/aspnetcore/new-db.html
Processus de build ou de release ?
Dans notre cas nous utilisons l’industrie logicielle de Visual Studio Team Services pour nos développements logiciels. Une partie des services fournis sont ceux de build et de release management.
Dans notre cas nous avons une séparation évidente entre le processus de build et de release.
Le processus de build a la responsabilité de :
Transformer le code source en livrable (compilation, transpilatation,…)
Transmettre les artifacts additionnels de release (scripts)
Exécuter les tests unitaires
Le processus de release a la responsabilité de :
Déployer les livrables sur les environnements cibles
Migrer les données
Configurer les environnements
…
Du coup il est logique pour nous d’effectuer la mise à jour du schéma dans le processus de release. Selon la manière dont est « monté » votre cycle de livraison continue ce sera peut-être un peu différent et il faudra adapter les exemples
Configuration des définitions dans VTSTS
Script d’exécution de la mise à jour
La première chose qu’on va vouloir ajouter à notre « code » est un script qui va demander à dnx d’exécuter la mise à jour de la base de données ainsi qu’un élément de configuration qui va permettre de configurer le contexte de base de données.
Heureusement pour vous c’est du travail que j’ai déjà fait voici donc les deux gist.
https://gist.github.com/baywet/9931ba2f45043dba9bdb
https://gist.github.com/baywet/ad41ccb8ad0bb12184ae
Récupération des sources et des scripts
Ce qu’il faut bien comprendre c’est que DNX se base sur le code source qu’il va compiler à la volée pour effectuer la migration. Il n’y a pas pour le moment et à ma connaissance de possibilité d’effectuer cela sur une librairie DNX (un nuget en clair) déjà compilée.
Ce que ça veut dire c’est que nous allons avoir besoin des sources afin de pour exécuter la migration entity framework. Sources que vous avez déjà sous la main si vous effectuez ça depuis le processus de build. Dans notre cas on effectue cela dans le processus de déploiement cependant.
Ce que ça signifie c’est que si, comme nous, vous effectuez votre mise à jour de base de données depuis le processus de release, il va falloir ramener les sources, sinon vous pouvez passer cette étape.
Rendez vous donc dans votre processus de build, et dans l’étape « copy files » rajouter une ligne src\** (toutes nos sources se trouvent dans src, c’est la pratique avec DNX) et une ligne *.ps1 pour ramener le script récemment ajouté.
Mise à jour du schéma pendant le déploiement
Enfin la dernière étape est de demander à votre processus de release d’effectuer la mise à jour de la base de données. Pour cela simplement rajouter une étape powershell avec en paramètre le chemin du script et en argument la connection string de la base de données à mettre à jour.
Conclusion
Comme vous pouvez le voir il est assez simple d’automatiser et de maitriser la mise à jour des schémas de base de données avec Entity Framework code first dans un release pipeline. Et ce avec DNX ou non.
J’espère que cet article vous fera gagner du temps à tous et vous évitera des problèmes de déploiement.