Mise à jour maitrisée de schema SQL avec Entity Framework Code First dans un processus de livraison continue

Mar 3, 2016

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é.

61.png

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.

62.png

Conclusion

63.png

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.


Edité la dernière fois le 6 Sep 2021 par Vincent


Tags: