Risposta.

Nell'architettura a microservizi, ogni servizio è spesso responsabile del proprio database. Per gestire le migrazioni dello schema dei dati è necessario utilizzare strumenti di migrazione specializzati (Liquibase, Flyway, Alembic), e avviarli tramite pipeline CI/CD per automatizzare e prevedere i risultati.

Una buona pratica è che ogni migrazione venga preparata come uno script di migrazione con versioning e Idempotenza — l'esecuzione ripetuta della stessa modifica non porterà a errori o incoerenze.

Esempio di migrazione in Python Alembic:

from alembic import op
import sqlalchemy as sa

def upgrade():
    op.add_column('user', sa.Column('status', sa.String(8)))

def downgrade():
    op.drop_column('user', 'status')

Caratteristiche chiave:

• Automazione delle migrazioni a livello CI/CD
• Idempotenza — possibilità di riapplicare senza danneggiare la struttura
• Versioning degli schemi dei dati e rollback

Domande insidiose.

È possibile modificare manualmente lo schema del DB in produzione senza migrazioni (DDL manuale)?

Questo è categoricamente sconsigliato: si perderà il controllo sullo stato dello schema e si verificheranno difficoltà nel rollback/tracciamento delle modifiche.

È vero che nelle architetture a microservizi le migrazioni devono essere eseguite centralmente per tutti i servizi?

No, ogni team/servizio è responsabile del proprio schema e della propria pipeline di migrazioni. La centralizzazione contraddice i principi di indipendenza dei servizi.

Il rollback delle migrazioni è completamente sicuro?

No: non è sempre possibile annullare le modifiche, soprattutto se la struttura o la forma dei dati sono cambiate (ad esempio, se un campo è stato rimosso e i dati persi). È meglio progettare le migrazioni tenendo conto del rollback.