Ответ.

В многосервисной архитектуре каждый сервис часто отвечает за собственную базу данных. Для управления миграциями схем данных нужно применять специализированные инструменты миграций (Liquibase, Flyway, Alembic), а запускать их — через CI/CD pipeline для автоматизма и предсказуемости результатов.

Хорошая практика — каждая миграция подготавливается как миграционный скрипт с версионированием и Idempotency — повторный запуск одного и того же изменения не приведет к ошибке или рассогласованию.

Пример миграции на 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')

Ключевые особенности:

• Автоматизация миграций на уровне CI/CD
• Idempotency — возможность повторного применения без ущерба структуре
• Версионирование схем данных и откат

Вопросы с подвохом.

Можно ли изменять схему БД вручную на проде без миграций (ручной DDL)?

Это категорически не рекомендуется: потеряется контроль над состоянием схемы и возникнут сложности с откатом/отслеживанием изменений.

Правда ли, что при микросервисной архитектуре миграции должны выполняться централизованно для всех сервисов?

Нет, каждая команда/сервис отвечает за свою схему и свой pipeline миграций. Централизация противоречит принципам независимости сервисов.

Является ли rollback миграций полностью безопасным?

Нет: не всегда можно откатить изменения, особенно если структура или форма данных изменилась (например, если поле было удалено и данные потеряны). Лучше проектировать миграции с учётом отката.