Vue d’ensemble
Kit’Asso utilise 43 fichiers de migration SQL qui tracent l’évolution complète du schéma de base de données. Chaque migration est versionnée avec un timestamp et documentée pour faciliter le déploiement et le rollback. Convention de nommage :- Historique complet des changements de schéma
- Déploiement reproductible sur tous les environnements
- Rollback possible en cas d’erreur
- Documentation intégrée dans les fichiers SQL
Structure d’une migration
Migration complète typique
Fichier :20240115103000_create_tools_table.sql
Chronologie des migrations
Phase 1 : Tables Core (Migrations 1-15)
Migrations principales :- Création des tables fondamentales (tools, categories, filters)
- Relations many-to-many avec tool_features
- Indexes pour performance
- RLS policies pour sécurité
- Table site_assets pour gestion centralisée
Phase 2 : Workflows (Migrations 16-25)
Migrations principales :- Table workflows avec champs JSONB (steps, next_steps, resources)
- Table workflow_steps avec contenu enrichi (story, visuals, videos)
- Contraintes CHECK pour difficulty et status
- Policies RLS distinctes pour workflows actifs vs drafts
- Indexes sur status et display_order
Phase 3 : Tool Packs (Migrations 26-32)
Migrations principales :- Table tool_packs avec icon, color, difficulty
- Table pack_tools (join table avec display_order)
- Contraintes UNIQUE sur (pack_id, tool_id)
- Status active/draft pour packs
- Policies pour filtrer packs actifs côté public
Phase 4 : Quiz System (Migrations 33-43)
Migrations principales :- Tables pour quiz complet (quizzes, questions, answers, recommendations, responses)
- Champ JSONB condition_logic pour recommandations
- Policies complexes (public insert sur responses, read via parent quiz)
- Slug unique pour routing
- Arrays UUID pour recommended_pack_ids et recommended_tool_ids
Processus de déploiement
Environnement local
Prérequis :- Projet Nhost créé avec accès à la console Hasura
- Accès au SQL runner dans Hasura Console
- Ouvrir Dashboard Nhost → Hasura → Open Hasura Console
- Aller dans l’onglet SQL
- Copier le contenu de la migration
- Exécuter le SQL
- Vérifier le résultat dans l’onglet Data
Environnement de production
Processus complet :- ✅ Backup effectué
- ✅ Migrations testées en local
- ✅ RLS policies vérifiées
- ✅ Indexes créés
- ✅ Contraintes validées
- ✅ Données de test insérées
- ✅ Frontend fonctionne avec nouveau schéma
Ordre d’exécution des migrations
CRITIQUE : Respecter l’ordre chronologiqueRollback de migrations
Rollback simple (dernière migration)
Créer un fichier de rollback : Fichier :20240118110000_add_quiz_condition_logic_rollback.sql
Rollback complet (retour à version antérieure)
Option 1 : Restauration depuis backupMigrations réversibles
Pattern de migration avec UP et DOWN :Bonnes pratiques
✅ À faire
Toujours tester en local avant production❌ À éviter
Ne jamais modifier une migration déjà déployéeVérification post-migration
Checklist de validation
Ressources
Database Schema
Structure complète des 13 tables créées
RLS Policies
Sécurité appliquée dans les migrations
Nhost Setup
Configuration du projet Nhost
Nhost Storage
Configuration du Storage Nhost