database-migration-helper

Database Migration Helper

1. Qualifier le changement

Avant tout, caractériser l'opération :

Type	Risque	Stratégie recommandée
Ajout colonne nullable	Faible	Migration directe
Ajout colonne NOT NULL sans default	Élevé	Expand-contract obligatoire
Renommage colonne/table	Élevé	Alias + expand-contract
Suppression colonne/table	Élevé	Phase contract après code nettoyé
Changement de type	Élevé	Colonne intermédiaire + backfill
Ajout index (grande table)	Moyen	Index CONCURRENTLY / online
Data migration (backfill)	Variable	Batches, jamais full-table en une passe

---

2. Choisir la stratégie

Expand-Contract (zero-downtime, recommandé pour prod)

Trois phases déployées séparément :

1. Expand — ajouter la nouvelle colonne/table, sans toucher à l'ancienne.
2. Migrate — double-écriture dans le code, backfill des données existantes.
3. Contract — supprimer l'ancienne colonne/table une fois le code nettoyé déployé.

Migration avec fenêtre de maintenance

Acceptable uniquement si : trafic < 100 rps OU table < 100k lignes OU downtime explicitement accepté par le métier.

Blue-Green

Maintenir deux environnements avec bascule DNS/load-balancer. Adapté aux changements majeurs de schéma impossibles à rendre backward-compatible.

---

3. Écrire la migration selon l'outil

EF Core (C#)

dotnet ef migrations add AddUserEmailIndex --project src/Infrastructure
dotnet ef database update --connection "Server=...;Database=...;"
# Rollback vers migration précédente
dotnet ef database update NomMigrationPrecedente

// Migration générée — toujours vérifier le SQL produit
protected override void Up(MigrationBuilder mb)
{
    mb.AddColumn<string>("email_verified", "users", nullable: true);
    mb.CreateIndex("IX_users_email", "users", "email", unique: true);
}
protected override void Down(MigrationBuilder mb)
{
    mb.DropIndex("IX_users_email", "users");
    mb.DropColumn("email_verified", "users");
}