Le database branching est une approche d’organisation de base de données qui permet de reproduire la dynamique et le fonctionnement des branches Git.
On va alors pouvoir à partir d’une base de données appelé “master” pouvoir dupliquer une “branche” avec un certain nom. Cette nouvelle base de données se vera hériter des données ainsi que des migrations de la branche source.
Les cas d’usages de ce principe sont multiples et variés. Si nous reprenons l’analogie avec Git flow, lorsque vous allez créer une nouvelle branche de feature, vous serez amené à devoir développer puis appliquer une migration de données ou bien tout simplement altérer les données contenues dans cette base. Elle devient à partir de là un bac à sable tout en partant d’un environnement déjà prédéfini.
Grâce à la nouvelle base de données mise en place pour votre feature, vous n’allez impacter aucun environnement de production / staging / dev mis en place et accessible par tous les développeurs.
Votre base de données sera alors unique et éphémère, une fois la feature terminée, celle-ci pourra être supprimée.
Elle peut aussi servir de base de données temporaire pour une démonstration client, alimentée de données bien précises pour cette dite démonstration.
Pour terminer cette introduction, j’ajouterai que le database branching est présent avant tout pour améliorer la “DX” des développeurs au quotidien.
Pourquoi ne pas alors simplement produire une base de données sur ma machine ?
Il est autant possible que l’infrastructure du projet mette à disposition un cluster de base de données sur un serveur ou bien qu’un développeur puisse créer son cluster sur sa machine.
Avec un provisionnement type Docker vous pouvez déployer rapidement une base de données sur votre machine avec un script de seeding permettant d’alimenter cette base en données. Cependant, vous allez perdre une composante essentielle au database branching qui est la synchronisation de la branche Git avec les données. En effet, si vous êtes plusieurs développeurs à intervertir sur cette feature / environnement, aucune manipulations supplémentaires ne sera à faire lors du passage sur la branche Git. Vous récupérez la base de données déjà préparée par le précédent développeur.
Vous allez aussi avoir la problématique d’espace disponible sur votre machine, si vous travaillez sur plusieurs branches en même temps, cela implique de pouvoir posséder un conteneur d’une base de données unique par branche. Donc, une grande quantité de données en local.
Comment s’intègre le Database branching dans le workflow du développeur
Comme n’importe quel outil s’ajoutant sur une stack d’un projet, le database branching viens complexifier quelques aspects techniques de celui-ci.
Alors, il est nécessaire d’automatiser le maximums d’aspects du database branching afin de ne pas augmenter le nombre de tâches à réaliser par les développeurs lors de la création d’une nouvelle feature.
En laissant certaines tâches manuelles, nous risquons de frustrer nos collègues développeurs. En effet, il est très facile d’oublier d’exécuter une certaine commande après un changement de branche.
Dans la deuxième partie de l’article nous nous intéresseront à réaliser un environnement de développement fluide avec l’exemple d’une stack web.
Je dirai alors que le database branching idéal est celui qui est complètement transparents pour les développeurs.
Dans la finalité ce principe est plus ou moins une idéologie, le degrés de l’implémentation peut dépendre de l’envergure du projet et du nombre de développeurs.
Tutoriel: Mise en place du database branching sur une stack Typescript, Prisma
Initialisation du projet et de la base de donnée
La première étape de ce tutoriel sera de se munir d’une base de données avec un utilisateur ayant l’autorisation de créer des database supplémentaires.
Voici plusieurs providers proposant ce service:
Actuellement nous utilisons une base de données hébergée Aurora Serverless hébergée sur AWS déployée depuis Terraform avec le module suivant.
Pour la suite de ce tutoriel nous avons choisis d’utiliser une base de données PostgreSQL. Il est aussi tout à fait possible de l’intégrer sur une base de données MongoDB, MySQL, …
Pour passer rapidement sur les étapes d’initialisation du projet TS avec Prisma je vous redirige vers la documentation officielle de Prisma.
Après toutes ces étapes vous devriez avoir dans la racine de votre projet un fichier d’environnement nommé .env qui possède une url de base de données DATABASE_URL.
À présent nous pouvons remplacer cette url par celle de notre base de données provisionnée un peu plus haut.
DATABASE_URL="postgresql://gabriel:password@db-branching.cluster-xxxxxxx.eu-west-3.rds.amazonaws.com:5432/master?schema=public"
La database pointée (master dans ce cas-là) importe peu, elle sera mise à jour par la suite automatiquement.
Automatisation du changement de branche
Afin de faciliter le passage sur une nouvelle base de données à chaque changement de branche git, il est possible de créer un hook sur le projet git, qui sera exclusivement lancé lors d'une commande git checkout.
Pour celà nous utiliserons un outil facilitant la création de hook git nommé Husky.
Voici les commandes d’installation que vous pouvez retrouver dans la documentation officielle:
.png)
Cette dernière commande va alors créer un script bash dans le dossier suivant.husky/post-checkout.
On ajoutera ces trois lignes de bash permettant de récupérer la branche git lors d’un checkout et de mettre à jour le fichier .env
.png)
Et voilà !
Maintenant à chaque changement de branche en local votre .env sera mis à jour automatiquement.
Il est possible d’aller plus loin en ajoutant l’application automatique des migrations de la base données et/ou le seeding de data.
.png)
.png)
.png)
.png)
