Pourquoi vous devriez toujours tester vos migrations de base de données en mode dry-run avant de toucher aux données réelles

Vous avez écrit un script de migration. Il a l'air correct. La logique est bonne. Vous l'exécutez en staging, tout passe. Mais en production, quelque chose cloche. Une contrainte de colonne échoue. Une violation de clé étrangère apparaît. La migration prend 45 minutes au lieu des 5 prévues, verrouille une table critique et provoque une cascade de timeouts dans toute votre application.

Ce scénario est courant. Et il est évitable. La technique est simple : exécutez votre migration en dry-run avant de la laisser toucher aux données réelles.

Ce que fait réellement un dry-run

Un dry-run est exactement ce que son nom indique. Vous exécutez votre script de migration, mais vous ne validez jamais les changements. Aucune table n'est modifiée. Aucune ligne n'est déplacée. Aucune colonne n'est supprimée. Vous vérifiez simplement si le script s'exécute sans erreur, et en cas de problème, vous le découvrez avant que les données ne soient affectées.

La méthode la plus courante consiste à encapsuler votre migration dans une transaction et à la terminer par ROLLBACK au lieu de COMMIT. Si vous avez un script qui ajoute une nouvelle colonne et la remplit à partir d'une autre table, vous encapsulez le tout dans BEGIN TRANSACTION ... ROLLBACK. Si une erreur survient en cours de route, la transaction s'annule automatiquement et la base de données revient à son état initial. Si aucune erreur ne se produit, vous annulez manuellement. Vous ne cherchez pas à appliquer le changement. Vous cherchez une confirmation que le script est valide.

Voici un exemple concret de ce à quoi cela ressemble en SQL :

BEGIN TRANSACTION;

-- Exemple de migration : ajouter une nouvelle colonne et la remplir
ALTER TABLE users ADD COLUMN last_login_at TIMESTAMP;

UPDATE users
SET last_login_at = NOW()
WHERE last_login_at IS NULL;

-- Vérifier que les données semblent correctes avant d'annuler
SELECT id, email, last_login_at FROM users LIMIT 10;

-- Annuler la transaction, laissant la base de données inchangée
ROLLBACK;

Ce qu'un dry-run vous apprend au-delà des erreurs de syntaxe

Vérifier les erreurs de syntaxe ou les violations de contraintes est l'avantage évident. Mais un dry-run vous donne des informations bien plus utiles.

Vous pouvez voir combien de temps la migration prendra. Vous pouvez voir combien de lignes seront affectées. Vous pouvez voir si la migration verrouillera des tables et pendant combien de temps. Ce sont des informations cruciales, surtout si votre migration cible une base de production qui gère des milliers de requêtes par seconde. Si votre dry-run montre que la migration prendra 30 minutes et que pendant ce temps la table principale sera verrouillée, vous savez qu'il faut une stratégie différente. Peut-être exécuter la migration pendant les heures creuses. Peut-être utiliser une technique de migration en ligne qui évite les verrous longs. Peut-être diviser la migration en lots plus petits.

Sans dry-run, vous devinez. Avec un dry-run, vous avez des données pour prendre une décision éclairée.

Où exécuter votre dry-run

L'endroit idéal est un environnement de staging avec des données qui ressemblent beaucoup à la production. Mais toutes les équipes n'ont pas une base de staging avec un volume de données réaliste. Si c'est votre cas, prenez un snapshot des données de production à un instant donné et chargez-le dans une base séparée. Ce snapshot ne doit jamais être utilisé pour des transactions réelles, mais il est suffisant pour tester votre migration.

Certaines équipes vont plus loin et automatisent les dry-runs. Chaque fois qu'un script de migration change dans une pull request, un job CI exécute le dry-run automatiquement. Cela détecte les problèmes avant même que le code ne soit fusionné. C'est un petit investissement qui fait gagner un temps de débogage considérable par la suite.

Comment interpréter les résultats d'un dry-run

Une sortie propre, sans erreur ni avertissement, est rassurante. Mais ne vous arrêtez pas là. Parcourez attentivement les logs.

Recherchez les lignes qui n'ont pas pu être remplies car les données ne correspondaient pas au nouveau type de colonne. Recherchez les conflits d'index. Recherchez les violations de clés étrangères. Parfois, un dry-run réussit techniquement mais échoue logiquement. Par exemple, les données que vous avez déplacées pourraient être vides parce que votre clause WHERE était erronée. Le script s'est exécuté correctement. Aucune erreur. Mais le résultat est inutile.

Pour détecter cela, après la fin du dry-run, exécutez une requête SELECT pour vérifier le contenu de la table modifiée comme si la migration avait réellement eu lieu. Vous pouvez le faire dans la même transaction avant d'annuler. Ouvrez une session séparée, exécutez la migration dans une transaction, et avant d'annuler, interrogez les tables modifiées pour confirmer que les données sont correctes. Cette étape supplémentaire transforme un dry-run d'une simple vérification syntaxique en une vérification logique.

Ce qu'un dry-run ne peut pas garantir

Un dry-run ne garantit pas que la migration se déroulera sans accroc en production. Certains facteurs ne peuvent pas être entièrement reproduits. La charge de requêtes concurrentes sera différente. Le volume de données peut être beaucoup plus important. Le timing des verrous peut changer. Mais un dry-run réduit les surprises. Si vous avez testé la migration dans un environnement proche de la production et que les résultats correspondent à vos attentes, vous pouvez exécuter la vraie migration avec une confiance bien plus grande.

Liste de contrôle pratique avant d'exécuter une migration

Avant d'exécuter une migration qui touche aux données de production, parcourez cette courte liste :

• Encapsulez la migration dans une transaction et exécutez-la avec ROLLBACK
• Vérifiez le temps d'exécution et la durée de verrouillage
• Vérifiez que le nombre de lignes affectées correspond aux attentes
• Interrogez les tables modifiées dans la transaction pour confirmer l'exactitude des données
• Passez en revue les logs pour détecter les violations de contraintes, les conflits d'index ou les incompatibilités de type
• Si la migration prend trop de temps ou verrouille trop lourdement, planifiez une stratégie alternative

L'essentiel à retenir

Un dry-run n'est pas une étape supplémentaire. C'est l'étape qui sépare un déploiement confiant d'un déploiement stressant. Exécutez votre migration dans une transaction. Annulez-la. Vérifiez les résultats. Ensuite, décidez si vous êtes prêt à valider. Vos données de production vous remercieront.