Prisma en production : vérifier les migrations avant de modifier une base contenant des données

Une application créée avec l’IA peut fonctionner avec une base locale et échouer une fois publiée. Créer des tables sur un autre serveur, transférer les enregistrements et modifier le schéma d’une base contenant déjà des données sont trois opérations différentes. Une migration Prisma ne copie pas automatiquement les lignes de votre ordinateur vers la production.

Ce guide est préparé pour Prisma 7.10.0, avec une version fixée dans le projet. La documentation actuelle décrit aussi des commandes de Prisma 8 : vérifiez la version installée avant de copier une procédure. L’essai local décrit ci-dessous est terminé ; il ne démontre pas une intégration native à Hostbrid.

Identifiez d’abord la base que vous allez modifier

Si la destination est vide et que vous disposez d’un historique de migrations vérifié, vous pouvez lui appliquer cet historique. Si des tables ou des données existent déjà, examinez la création du schéma et vérifiez que Prisma dispose d’un historique correspondant. L’erreur P3005, « database schema is not empty », ne se résout pas en supprimant une base à conserver.

Une base existante peut nécessiter une baseline : une migration initiale représentant son schéma existant, enregistrée comme appliquée après vérification de cette correspondance. Ne marquez pas un fichier quelconque comme appliqué pour masquer une erreur. Une marque incorrecte laisse l’historique et le schéma réel dans des états différents et peut reporter le problème à la prochaine livraison.

Si vous souhaitez aussi transférer les données de votre ordinateur, préparez une opération distincte d’exportation et d’importation, avec des versions compatibles et une destination adaptée. Vérifiez qui continuera à écrire pendant le transfert. Une capture montrant des tables créées ne prouve pas que toutes les lignes, relations ou séquences sont arrivées.

N’utilisez pas la commande de développement pour la livraison en production

Dans Prisma 7, migrate dev génère et applique des migrations en développement ; il peut détecter des différences nécessitant une réinitialisation. migrate reset supprime les données. migrate deploy applique les migrations existantes en attente : il ne génère ni une nouvelle migration ni le client à votre place et ne vérifie pas toutes les différences du schéma.

Cela ne fait pas de migrate deploy une garantie de conservation. Si le fichier SQL contient un DROP TABLE, une suppression de colonne ou une transformation erronée, son application peut détruire des informations. Examinez la modification SQL, pas seulement le message final de la commande. Fixer la version et conserver le lockfile rend l’essai reproductible ; cela ne rend pas toute modification correcte.

Testez avec des enregistrements permettant de détecter une perte

Travaillez sur une base jetable que vous contrôlez. Incluez des enregistrements avec des identifiants connus, des relations et des valeurs devant subsister. Comparez ces valeurs avant et après, pas seulement le nombre de lignes. Deux tables peuvent compter autant de lignes et contenir des données différentes.

Un nouveau champ obligatoire nécessite une stratégie pour les lignes existantes. Vous pouvez l’introduire en autorisant les valeurs nulles, compléter les valeurs par une transformation explicite, puis imposer la contrainte après avoir vérifié qu’il ne reste aucun null. Vérifiez aussi les contraintes d’unicité et les clés étrangères nécessaires à l’application.

Appliquez à nouveau l’historique à la même destination pour vérifier ce qui reste en attente. Ce résultat ne remplace ni l’examen du SQL, ni un essai de récupération, ni la compatibilité entre l’ancienne et la nouvelle version de votre application. Une sauvegarde jamais restaurée ne prouve pas que vous pouvez rétablir le service.

Décidez d’où la migration pourra être exécutée

Une DATABASE_URL contient des informations d’accès privées ; ne la placez ni dans des variables publiques comme VITE_, ni dans le dépôt, ni dans des exemples partagés. Le processus exécutant la migration doit pouvoir atteindre la base et disposer des permissions adaptées aux modifications approuvées. L’application en fonctionnement peut nécessiter d’autres permissions.

Hostbrid propose des bases relationnelles et décrit un réseau privé par défaut sur sa page des bases de données. Vérifiez comment le processus de migration atteindra ce réseau avant d’acheter ou de connecter un CI externe. Ce guide ne démontre ni un accès depuis tout fournisseur de CI ni une configuration automatique de Prisma. Consultez les offres actuelles et confirmez le moteur et la connectivité nécessaires à votre application.

Si vous ne savez pas encore quelle partie du projet nécessite un serveur, commencez par choisir l’hébergement d’un site créé avec une IA. Publier le frontend et maintenir une base de production sont des décisions liées qui nécessitent leurs propres vérifications.

Ce que nous avons vérifié dans l’exemple original

Le 8 octobre, nous avons testé 12 cas avec Prisma 7.10.0, Node 22.23.3, npm 10.9.9 et PostgreSQL 16.13 Homebrew sur macOS ARM64. Le cluster était neuf et local, avec deux comptes et deux entrées fictifs. Nous n’avons connecté aucune base Hostbrid ni base de client.

La migration additive a conservé chaque champ original, identifiant et relation ; le backfill a produit les noms attendus. Les contraintes ont rejeté les doublons et les références invalides. La branche de base existante a reproduit P3005 avant le baseline ; un baseline correct et un diff sans différences ont permis la migration additive. Avec un baseline incorrect, resolve a réussi, mais le diff a détecté les contraintes absentes et l’essai n’a pas poursuivi cette branche.

Nous avons restauré le dump dans trois bases neuves et comparé les données. Dans une autre copie, un DROP COLUMN a réussi et supprimé des valeurs : conserver le nombre de lignes ne suffisait pas. L’ajout d’une colonne obligatoire sans compléter les lignes existantes a échoué ; le deploy suivant était bloqué. Ces résultats négatifs étaient attendus et ne concernaient que des données fictives.

Le serveur a été arrêté et cet arrêt vérifié. L’essai ne couvre pas les grandes tables, la concurrence, la durée des blocages, le PITR, les sauvegardes de fournisseur ni l’exécution des migrations dans Projects.

Prisma 7 migrate deploy · Prisma 7 baselining

Exécutez l’essai dans un environnement jetable

L’exemple original MIT est fixé à la révision 87a2a843867be8b6244a68fbc50b3919f4d2b82e. Il nécessite macOS ARM64, Node 22.23.3, npm 10.9.9, PostgreSQL 16.13 Homebrew installé et le port local 55439 libre. PG_BIN permet de choisir le dossier des binaires. N’adaptez pas ces contre-exemples pour une base réelle : le runner crée et arrête son propre cluster et ignore une DATABASE_URL reçue.

git clone https://github.com/ocentelles/hostbrid-example-prisma-migrations.git
cd hostbrid-example-prisma-migrations
git checkout --detach 87a2a843867be8b6244a68fbc50b3919f4d2b82e
node --version
npm --version
npm ci --ignore-scripts --no-audit --no-fund
npm run essay