Gestion des migrations de bases de données

Stratégie de migration d’une base de données dans le cadre d’une architecture orientée microservices

Dans le cadre d’une architecture orientée microservices, chaque “domaine” (i.e. les microservices qui interviennent au sein d’une même section du contexte métier) a la responsabilité de la cohérence de ses données.

Cette responsabilité induit qu’au sein d’une architecture distribuée, chaque domaine ayant une dépendance sur une base de données doit assurer les migrations de celles ci , que ce soit au niveau du schéma pour une base de données relationnelle comme au niveau de l’évolution applicative de gestion du modèle de données dans le cas de base de données “NoSQL”.

Base de données relationnelle: principes généraux de migration

Il est communément admis que l’évolution des migrations et celui de la base de code doivent être (dans la mesure du possible) décorrélés afin de maintenir un cycle sain de livraison des mises à jour.

L’utilisation des mécanismes de migrations intégrés aux différents frameworks ORM est ainsi fortement déconseillé.

L’usage d’outils dédiés à la gestion du cycle d’évolution du schéma de la base de données est fortement recommandé (voir la section “Outils dédiés”).

Le principe généralement mis en avant est de considérer toute modification du schéma comme une opération atomique rétrocompatible avec l’environnement applicatif à un instant T.

Par exemple, le changement de type d’une colonne devrait être géré de la manière suivante:

  1. Livraison 1 Ajout d’une nouvelle colonne avec le nouveau type dans la base de données
  2. Livraison 2 à N: Mise à jour du code des services utilisant les données de l’ancienne colonne afin qu’ils enregistrent également les données dans la nouvelle colonne avec le nouveau format. En cas d’absence de données dans la nouvelle colonne, les services mis à jour doivent être capable de basculer sur l’ancienne colonne. Les services mis à jour doivent considérer l’ancienne colonne comme potentiellement absente. Cette migration peut se faire de manière progressive sur les services, les deux colonnes pouvant coexister.
  3. Livraison N+1: Lorsque l’ensemble des services du domaine ont été mis à jour, il est possible de supprimer l’ancienne colonne en s’assurant que toutes les données ont bien été déplacées par l’application vers la nouvelle colonne.
  4. Livraison N+2 à M: Le code servant à gérer la coexistence des deux colonnes peut être supprimé progressivement des services.

Cette stratégie s’adapte particulièrement bien à la méthodologie “agile” car elle permet de faire évoluer le modèle de données de l’application de manière progressive (et donc d’éviter d’impacter négativement le rythme des livraisons).

Globalement, la stratégie serait identique dans le cas d’usage d’une base de données sans schéma (“NoSQL”), minus les livraisons de migration du schéma.