Antwoord.

In een microservicesarchitectuur is elke service vaak verantwoordelijk voor zijn eigen database. Voor het beheren van schema-migraties moeten gespecialiseerde migratietools (Liquibase, Flyway, Alembic) worden toegepast, en deze moeten via een CI/CD-pipeline worden uitgevoerd voor automatisering en voorspelbaarheid van de resultaten.

Een goede praktijk is dat elke migratie wordt voorbereid als een migratiescript met versiebeheer en idempotentie — het opnieuw uitvoeren van dezelfde wijziging leidt niet tot een fout of inconsistentie.

Voorbeeld van een migratie 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')

Belangrijke kenmerken:

• Automatisering van migraties op CI/CD-niveau
• Idempotentie — de mogelijkheid om opnieuw toe te passen zonder schade aan de structuur
• Versiebeheer van datamodellen en rollback

Valstrikvragen.

Is het toegestaan om het datamodel handmatig aan te passen in productie zonder migraties (handmatige DDL)?

Dit wordt ten zeerste afgeraden: er zal controle verloren gaan over de toestand van het schema en er ontstaan complicaties bij het terugdraaien/volgen van wijzigingen.

Is het waar dat bij een microservicesarchitectuur migraties centraal moeten worden uitgevoerd voor alle services?

Nee, elk team/service is verantwoordelijk voor zijn eigen schema en zijn eigen migratiepipeline. Centralisatie gaat in tegen de principes van service-onafhankelijkheid.

Is rollback van migraties volledig veilig?

Nee: het is niet altijd mogelijk om wijzigingen terug te draaien, vooral als de structuur of vorm van gegevens is veranderd (bijvoorbeeld als een veld is verwijderd en de gegevens verloren zijn gegaan). Het is beter om migraties te ontwerpen met het oog op terugdraaien.