[Part 1] Créer un workflow GitOps pour vos migrations SQL

Découvrez comment mettre en place un workflow GitOps pour gérer vos migrations SQL en utilisant DbMate et Docker, facilitant ainsi le travail d'équipe et l'intégration continue.

18 septembre 2023

Published

Hugo Mufraggi

Author

3 min read
[Part 1] Créer un workflow GitOps pour vos migrations SQL

Part 1 Créer Un Workflow Gitops Pour Vos Migration Sql

Nouvelle série d’article, elle sera composée de plusieurs articles. Le but, vous embarquez avec moi à la recherche d’un workflow répondant à mes attentes.

Attentes

  • Pouvoir avoir dans un repos toutes mes migrations centralisées.(Pour un projet)
  • Que la solution choisie repose le plus possible sur du SQL pure.
  • Ne pas dépendre d’un ORM.
  • Avoir un workflow de travail facile, teams friendly.
  • Réussir à avoir un bon workflow de CI-CD.

Cet article couvre toute la partie teams workflow et travaille en local. Ca sera aussi l’occasion de jouer nos premières migrations avec Dbmate.

Local workflow

Les objectifs du flow en local sont de faciliter le travail des autres développeurs·euses. De pouvoir rapidement lancer une DB en local et travailler. Je veux avoir le moins de package à installer, en l’occurence un DBmate. Les différentes commandes seront wrapper dans un makefile. J’y vois plusieurs avantages d’unification des commandes , de couplage avec DbMate et d’auto complétion + help pour les commandes à taper. Pour finir, nous utiliserons Docker pour lancer une base de donnée en local.

Dbmate

Aprés quelques recherches, j’ai choisi le dbmate. Le projet est simple et support ,PostgreSQL, MySQL, SQLite et ClickHouse. Pour cet article, nous utiliserons une base de donnée postgres dans un conteneur Docker. Je vous invite à lire la doc de Dbmate et ajouter une stars au passage.

Makefile

80% de ce que je vous présente tient dans le makefile. J’ai mis seulement le strict minimun dedans. Les Commandes pour migrer en préprod et prod ne seront pas là, le but étant de créer un workflow structuré à l’aide de ci-cd, mais cela sera pour le prochain article.

Voici une liste des commandes que nous allons vouloir implémenter:

  • Lancer une db postgres avec Docker.
  • Arrêter et suprimer le conteneur Docker.
  • Créer une nouvelle migration.
  • Jouer les migrations en attente.
  • Pouvoir rollback la dernière migration.
  • Print l’url et les potentiels variable d’env que la·le développeur·euse aura besoin.

Pour des questions de facilité, le plus de chose possible sera variabilisé.

Docker postgres

DB_CONTAINER_NAME := my-postgres
DB_VOLUME_NAME := my-postgres-volume
DB_PORT := 5432
DB_NAME := mydb
DB_USER := user
DB_PWD := password

.PHONY: start-db-container
start-db-container:
  docker run --name $(DB_CONTAINER_NAME) \\
    -v $(CURDIR)/data:/var/lib/postgresql/data \\
    -e POSTGRES_USER=$(DB_USER) \\
    -e POSTGRES_PASSWORD=$(DB_PWD) \\
    -e POSTGRES_DB=$(DB_NAME) \\
    -p $(DB_PORT):$(DB_PORT) \\
    -d postgres
.PHONY: stop-db-container
stop-db-container:
   docker stop $(DB_CONTAINER_NAME)
   docker rm $(DB_CONTAINER_NAME)

Pour le start-db-container j’ai ajouté un volume pour que si la·le développeur·euse suprime le container, la data persiste et qu’il.elle puisse au besoin y accéder à nouveau. Le volume sera dans un dossier data à la racine du repository. Pour le stop-db-container, pas grand chose à dire dessus si ce n’est que l’on stop le container et le supprime dans la foulée.

Dbmate

.PHONY: new
new:
  dbmate -u "postgres://$(DB_USER):$(DB_PWD)@localhost:$(DB_PORT)/$(DB_NAME)" new $(migration_name)

.PHONY: migrate
migrate:
 dbmate -u "postgres://$(DB_USER):$(DB_PWD)@localhost:$(DB_PORT)/$(DB_NAME)?sslmode=disable" up

.PHONY: rollback
rollback:
 dbmate -u "postgres://$(DB_USER):$(DB_PWD)@127.0.0.1:$(DB_PORT)/$(DB_NAME)?sslmode=disable" down

Le workflow que j’ai imaginé est le suivant:

  1. On crée une nouvelle migration avec new et la commande suivante make new migration_name=create_comment_table. Dbmate va créé un fichier dans db/migrations . Il vous restera juste à ajouter le code de votre migration dedans.
  2. Jouer sa migration avec make migrate.
  3. Si besoin rollback la dernière migration avec un make rollback.

Conclusion

Vous avez tous.tes les briques pour commencer à implémenter un flow de management de migrations sql en local. Dans le prochain article, on verra comment structurer une CI-CD et automatiser les migrations en prod préprod. Vous pourrez retrouver mon code sur ce repo.

A bientot