Définition
Une migration de base de données est un script versionne qui modifie le schéma d'une base de données de manière reproductible et reversible. Les migrations permettent de versionner le schéma comme on versionne le code source, en appliquant les changements de manière incrementale.
C'est un outil indispensable pour le travail en équipe et le déploiement continu.
Pourquoi des migrations ?
Sans migrations
- Modifications manuelles en production (ALTER TABLE à la main)
- Pas d'historique des changements de schéma
- Impossible de reproduire l'état de la BDD d'un collegue
- Risque de perte de données ou d'incoherence
Avec migrations
- Chaque changement est un script versionne
- Historique complet et auditable
- Reproductible sur n'importe quel environnement
- Rollback possible en cas de problème
Anatomie d'une migration
-- Migration: 001_create_users.sql
-- UP
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email VARCHAR(255) NOT NULL UNIQUE,
name VARCHAR(255),
created_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_users_email ON users(email);
-- DOWN (rollback)
DROP TABLE users;
Outils de migration par écosystème
| Écosystème | Outil | Approche |
|---|---|---|
| TypeScript | Drizzle | Push ou generate/migrate |
| TypeScript | Prisma | Schema-first, auto-generate |
| TypeScript | Knex | Code-first, JS/TS |
| Python | Alembic | Auto-detect, SQLAlchemy |
| Python | Django | Intégré au framework |
| Java | Flyway | SQL files |
| Java | Liquibase | XML/YAML/SQL |
| PHP | Laravel Migrations | Schéma builder |
| Go | golang-migrate | SQL files |
| Ruby | Active Record | Ruby DSL |
Exemple (Drizzle ORM)
# Generer une migration a partir du schema
npx drizzle-kit generate
# Appliquer les migrations
npx drizzle-kit migrate
# Ou push direct (dev)
npx drizzle-kit push
Bonnes pratiques
1. Migrations idempotentes
CREATE TABLE IF NOT EXISTS users (...);
ALTER TABLE users ADD COLUMN IF NOT EXISTS phone VARCHAR(20);
2. Pas de données dans les migrations de schéma
Separez les migrations de schéma (DDL) des migrations de données (DML).
3. Backward-compatible
En production avec zero-downtime deployment, la migration doit être compatible avec l'ancien ET le nouveau code :
- Ajoutez des colonnes avec des valeurs par défaut
- Ne renommez jamais directement (ajoutez → migrez les données → supprimez l'ancien)
- Ne supprimez jamais une colonne utilisee par le code actuel
4. Testez vos migrations
Testez sur une copie de la production avant d'appliquer. Vérifiez les rollbacks.