Storia della questione
Lavorare su progetti di grandi dimensioni richiede che la struttura del database si sviluppi parallelamente al codice dell'applicazione. Senza un controllo della versione software per le modifiche allo schema (aggiunte, rimozioni e modifiche di tabelle, indici, chiavi), il team perde rapidamente sincronia, aumenta il rischio di perdita di modifiche, fallimenti nelle migrazioni e complicazioni nel rollback o nella riproduzione dei bug.
Problema
L'approccio tradizionale — modifica manuale del DB tramite script SQL — porta a un ordine di esecuzione delle modifiche non evidente, difficoltà nel rollback, discrepanze di versione tra gli ambienti (dev, test, prod). Senza uno strumento comune per archiviare le migrazioni, è difficile capire chi, quando e perché ha modificato lo schema.
Soluzione
Per questo scopo vengono utilizzati sistemi di migrazione dello schema e pratiche di versioning del database. L'uso di strumenti (ad esempio, Liquibase, Flyway, Alembic per diversi DBMS) consente di archiviare gli script SQL delle modifiche allo schema direttamente nel sistema di controllo della versione (git), formare una rigorosa sequenza di migrazioni e automatizzare gli aggiornamenti dello schema in tutti gli ambienti.
Esempio di codice (migrazione tramite Flyway):
-- V002__add_column_email.sql ALTER TABLE users ADD COLUMN email VARCHAR(255) NOT NULL;
Integrazione di Flyway (ad esempio, per Java):
Flyway.configure().dataSource(url, user, pass).load().migrate();
Caratteristiche chiave:
È possibile archiviare lo "stato originale" dello schema (snapshot) invece delle migrazioni? A prima vista, un "dump" dell'intero schema è più semplice delle migrazioni. Ma sorgerebbero problemi con il rollback, il recupero di stati intermedi e la fusione di modifiche provenienti da diversi rami. Le migrazioni consentono di applicare solo nuove modifiche in modo sequenziale e nell'ordine corretto.
È necessario sincronizzare manualmente le migrazioni tra diversi ambienti? No, i moderni sistemi rispettano il versioning e applicano automaticamente solo quelle migrazioni che non erano già presenti nel database. L'importante è non la sincronizzazione manuale, ma l'applicazione automatizzata delle migrazioni durante il deployment.
Bastano solo gli script SQL delle migrazioni o è opportuno archiviare qualcos'altro? Una buona pratica è quella di archiviare oltre agli script SQL anche la loro descrizione (scopo, autore, data), nonché test-validatori per le nuove modifiche strutturali, per automatizzare il controllo della qualità delle migrazioni.
Il progetto utilizzava normali dump degli schemi e un'applicazione "manuale" delle modifiche da parte degli sviluppatori. Dopo il lancio dell'aggiornamento, il cliente notò che alcune nuove colonne non erano apparse nel database di produzione e che alcuni indici si duplicavano dopo ogni tentativo di aggiornare lo schema.
Vantaggi:
Veloce per progetti molto piccoli.
Svantaggi:
Difficoltà di supporto; impossibilità di capire cosa è stato modificato e da chi; impossibilità di rollback; diversi ambienti non coincidono.
Il team ha integrato Flyway, tutte le modifiche strutturali vengono eseguite tramite migrazioni con codice di revisione, il rollback di qualsiasi versione richiedeva solo pochi minuti, era facile eseguire test e controlli in tutti gli ambienti.
Vantaggi:
Automazione, storia, bassa probabilità di bug durante il deployment.
Svantaggi:
Necessità di documentare un po' di più ogni modifica strutturale.