Definition
Une migration de base de donnees est un script versionne qui modifie le schema d'une base de donnees de maniere reproductible et reversible. Les migrations permettent de versionner le schema comme on versionne le code source, en appliquant les changements de maniere incrementale.
C'est un outil indispensable pour le travail en equipe et le deploiement continu.
Pourquoi des migrations ?
Sans migrations
- Modifications manuelles en production (ALTER TABLE a la main)
- Pas d'historique des changements de schema
- Impossible de reproduire l'etat de la BDD d'un collegue
- Risque de perte de donnees 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 probleme
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 ecosysteme
| Ecosysteme | 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 | Schema 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 donnees dans les migrations de schema
Separez les migrations de schema (DDL) des migrations de donnees (DML).
3. Backward-compatible
En production avec zero-downtime deployment, la migration doit etre compatible avec l'ancien ET le nouveau code :
- Ajoutez des colonnes avec des valeurs par defaut
- Ne renommez jamais directement (ajoutez → migrez les donnees → 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. Verifiez les rollbacks.