Gouvernance de schéma : le pattern upgrade hook qui élimine les incidents de déploiement

Le problème que chaque équipe rencontre tôt ou tard

Vous avez migré vos données vers la base. Votre code lit les bonnes tables. Tout fonctionne — jusqu'au jour où une nouvelle fonctionnalité nécessite d'ajouter une colonne. Vous exécutez un ALTER TABLE en production, vous déployez le code, et vous réalisez quelques semaines plus tard que votre environnement de staging n'a pas la même colonne. La désynchronisation de schéma est la dette technique la plus silencieuse qui existe : elle ne produit pas d'erreur immédiate, elle produit des incohérences progressives qui se révèlent au pire moment.

Le pattern upgrade hook, issu de l'écosystème PrestaShop, résout ce problème structurellement. Voici comment l'adapter à n'importe quelle stack :

• Versionnez votre schéma avec votre code : chaque modification de table (ajout de colonne, nouvel index, nouvelle table) doit être accompagnée d'un fichier de migration versionné. Dans CodeMyShop : upgrade/upgrade-1.1.0.php contenant l'ALTER TABLE idempotent (IF NOT EXISTS).
• Bumpez le numéro de version du module : le module PrestaShop détecte le delta entre la version installée et la version disponible, et applique automatiquement le ou les hooks manquants lors du prochain déploiement.
• Laissez install.sql à jour pour les nouvelles installations : les environnements existants passent par les hooks, les nouvelles installations partent d'un schéma complet. Les deux chemins convergent vers le même état.

Pourquoi interdire les ALTER TABLE manuels

Un ALTER TABLE exécuté directement sur un serveur de production est un événement non tracé, non reproductible et non réversible. Si votre staging ou votre environnement de développement ne contient pas cette modification, la prochaine personne qui rejoindra l'équipe partira d'un schéma différent. La règle est absolue : aucune modification de schéma sans upgrade hook versionné. La seule exception tolérée est un correctif d'urgence, immédiatement formalisé en hook lors de la session suivante.

Cette discipline peut sembler contraignante. Elle l'est effectivement — et c'est précisément ce qui la rend efficace. Les contraintes qui coûtent de l'effort à l'instantané sont celles qui évitent les incidents qui coûtent des jours à corriger.

• Toute modification de schéma non versionnée est une bombe à retardement dans votre pipeline de déploiement.
• L'idempotence (IF NOT EXISTS) est la propriété qui rend un hook safe à rejouer sans risque.
• Un schéma reconstructible depuis le code est un schéma que vous pouvez auditer, partager et faire évoluer sans dépendance aux mains qui l'ont créé.