Odpowiedź.

W architekturze mikroserwisowej każdy serwis często odpowiada za swoją własną bazę danych. Do zarządzania migracjami schematów danych należy stosować wyspecjalizowane narzędzia do migracji (Liquibase, Flyway, Alembic), a ich uruchamianie powinno odbywać się przez pipeline CI/CD dla automatyzacji i przewidywalności wyników.

Dobrą praktyką jest przygotowanie każdej migracji jako skryptu migracyjnego z wersjonowaniem i idempotencją — ponowne uruchomienie tej samej zmiany nie powinno prowadzić do błędu ani niespójności.

Przykład migracji w Pythonie z użyciem 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')

Kluczowe cechy:

• Automatyzacja migracji na poziomie CI/CD
• Idempotencja — możliwość wielokrotnego stosowania bez uszczerbku dla struktury
• Wersjonowanie schematów danych i wycofywanie

Pytania z pułapką.

Czy można ręcznie zmieniać schemat bazy danych na produkcji bez migracji (ręczne DDL)?

To jest kategorycznie niezalecane: stracimy kontrolę nad stanem schemy i pojawią się trudności z wycofywaniem/śledzeniem zmian.

Czy prawdą jest, że w architekturze mikroserwisowej migracje powinny być wykonywane centralnie dla wszystkich serwisów?

Nie, każdy zespół/serwis odpowiada za swoją schemę i swój pipeline migracji. Centralizacja stanowczo sprzeciwia się zasadom niezależności serwisów.

Czy wycofanie migracji jest całkowicie bezpieczne?

Nie: nie zawsze można cofnąć zmiany, zwłaszcza jeśli struktura lub forma danych uległa zmianie (na przykład, jeśli pole zostało usunięte i dane zostały utracone). Lepiej projektować migracje z uwzględnieniem wycofania.