6 min lecture • Guide 753 of 877
Meilleures Pratiques de Migration de Base de Données
Les migrations de base de données nécessitent une planification et une exécution soigneuses. GitScrum aide à suivre les tâches de migration et à coordonner les déploiements en toute sécurité.
Planification des Migrations
Structure des Tâches de Migration
STORY DE MIGRATION DE BASE DE DONNÉES :
┌─────────────────────────────────────────────────────────────┐
│ DB-123 : Ajouter la table user_preferences │
├─────────────────────────────────────────────────────────────┤
│ │
│ OBJECTIF : │
│ Stocker les préférences de notification et d'affichage │
│ Requis pour : USER-456 (Feature paramètres notifications) │
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ SCRIPT DE MIGRATION : │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CREATE TABLE user_preferences ( ││
│ │ id BIGSERIAL PRIMARY KEY, ││
│ │ user_id BIGINT NOT NULL REFERENCES users(id), ││
│ │ preference_key VARCHAR(100) NOT NULL, ││
│ │ preference_value JSONB NOT NULL DEFAULT '{}', ││
│ │ created_at TIMESTAMP DEFAULT NOW(), ││
│ │ updated_at TIMESTAMP DEFAULT NOW(), ││
│ │ UNIQUE(user_id, preference_key) ││
│ │ ); ││
│ │ ││
│ │ CREATE INDEX idx_user_prefs_user ON ││
│ │ user_preferences(user_id); ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SCRIPT DE ROLLBACK : │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DROP TABLE IF EXISTS user_preferences; ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ CHECKLIST : │
│ ☐ Script de migration revu │
│ ☐ Script de rollback testé │
│ ☐ Exécuté sur staging avec succès │
│ ☐ Impact sur les performances évalué │
│ ☐ Pas de verrouillage sur grandes tables │
│ ☐ Fenêtre de déploiement planifiée │
│ ☐ Monitoring en place │
└─────────────────────────────────────────────────────────────┘
Évaluation des Risques
NIVEAUX DE RISQUE DES MIGRATIONS :
┌─────────────────────────────────────────────────────────────┐
│ │
│ RISQUE FAIBLE (Feu vert) : │
│ • Ajout d'une nouvelle table │
│ • Ajout d'une colonne nullable │
│ • Ajout d'index (si table petite) │
│ → Peut s'exécuter à tout moment │
│ │
│ RISQUE MOYEN (Attention) : │
│ • Ajout d'index sur grande table │
│ • Modification type de colonne (compatible) │
│ • Ajout NOT NULL avec default │
│ → Exécuter pendant faible trafic │
│ → Surveiller les performances │
│ │
│ RISQUE ÉLEVÉ (Précaution extra) : │
│ • Modification type de colonne (incompatible) │
│ • Suppression de colonne │
│ • Suppression de table │
│ • Grandes migrations de données │
│ → Fenêtre de maintenance requise │
│ → Équipe en standby pour problèmes │
│ → Plan de rollback détaillé │
│ │
│ RISQUE CRITIQUE (Préparation complète) : │
│ • Changements de schéma sur énormes tables (100M+ lignes) │
│ • Changements de clés étrangères │
│ • Modifications de clé primaire │
│ → Fenêtre de maintenance étendue │
│ → Backup complet avant │
│ → Approbation de la direction │
│ → War room pendant l'exécution │
└─────────────────────────────────────────────────────────────┘
Patterns de Migration Sûrs
Changements Rétrocompatibles
PATTERNS DE MIGRATION SÛRS :
┌─────────────────────────────────────────────────────────────┐
│ │
│ PATTERN 1 : EXPAND-CONTRACT │
│ │
│ OBJECTIF : Renommer colonne "name" en "full_name" │
│ │
│ ❌ RISQUÉ (une étape) : │
│ ALTER TABLE users RENAME name TO full_name; │
│ → Casse l'ancien code immédiatement │
│ │
│ ✅ SÛR (expand-contract) : │
│ │
│ Étape 1 (Expand) : Ajouter nouvelle colonne │
│ ALTER TABLE users ADD COLUMN full_name VARCHAR(255); │
│ │
│ Étape 2 : Double-écriture dans le code │
│ Écrire dans name et full_name │
│ │
│ Étape 3 : Backfill des données │
│ UPDATE users SET full_name = name WHERE full_name IS NULL; │
│ │
│ Étape 4 : Basculer les lectures │
│ Lire depuis full_name │
│ │
│ Étape 5 (Contract) : Supprimer ancienne colonne (plus tard)│
│ ALTER TABLE users DROP COLUMN name; │
│ │
│ Chaque étape est réversible et non-breaking │
│ │
└─────────────────────────────────────────────────────────────┘
Ajout de Colonnes NOT NULL
AJOUT SÛR DE COLONNE NOT NULL :
┌─────────────────────────────────────────────────────────────┐
│ │
│ OBJECTIF : Ajouter colonne "status" requise aux users │
│ │
│ ❌ RISQUÉ : │
│ ALTER TABLE users ADD COLUMN status VARCHAR(20) NOT NULL; │
│ → Échoue si la table a des lignes existantes │
│ │
│ ✅ APPROCHE SÛRE : │
│ │
│ Étape 1 : Ajouter colonne nullable avec default │
│ ALTER TABLE users ADD COLUMN status VARCHAR(20) │
│ DEFAULT 'active'; │
│ │
│ Étape 2 : Backfill lignes existantes (par lots) │
│ UPDATE users SET status = 'active' │
│ WHERE status IS NULL │
│ AND id BETWEEN 1 AND 10000; │
│ │
│ Étape 3 : Ajouter contrainte NOT NULL │
│ ALTER TABLE users ALTER COLUMN status SET NOT NULL; │
│ │
│ Étape 4 : Optionnel - retirer le default │
│ ALTER TABLE users ALTER COLUMN status DROP DEFAULT; │
│ │
│ POURQUOI PAR LOTS : │
│ Un gros UPDATE verrouille la table │
│ Lots de 10k-50k lignes minimisent le temps de verrou │
│ Exécuter pendant les périodes de faible trafic │
└─────────────────────────────────────────────────────────────┘
Meilleures Pratiques
Règles d'Or
| Règle | Application |
|---|---|
| Toujours un rollback | Script testé avant prod |
| Staging d'abord | Valider avant production |
| Pas de DDL en rush | Planifier les fenêtres |
| Petits changements | Une migration = un changement |
| Monitoring | Alertes pendant l'exécution |