Skip to main content

Migration Plan: db push → Prisma Migrate

План перехода с push-based на migration-based workflow.

Статус

✅ Завершено — goLoot перешёл на migration-based workflow.

Baseline миграция: 0001_init

1. Зачем​

Текущие проблемы (были)​

  • ❌ Нет истории изменений схемы
  • ❌ Schema drift между окружениями (dev ≠ prod)
  • ❌ Невозможен безопасный rollback
  • ❌ Team conflicts при изменении схемы
  • ❌ Production риски (db push может потерять данные)

После миграции​

  • ✅ История в git
  • ✅ Безопасный rollback
  • ✅ Team sync автоматически
  • ✅ Production-ready workflow

2. Безопасный план​

Этап 1: Baseline миграция (Dev) ✅​

Цель: Создать начальную миграцию из текущей схемы.

cd backend

# 1. Создать baseline миграцию
npx prisma migrate dev --name baseline_schema

# Prisma обнаружит drift и предложит reset
# Подтверждаем — БД пересоздаётся с миграцией

Результат:

  • Создана директория prisma/migrations/
  • Файл миграции: 0001_init/migration.sql (3019 строк)
  • БД в sync с миграцией
  • Seed выполнен автоматически
Дополнительные миграции

Все инкрементальные миграции были squashed в baseline 0001_init.

Этап 2: Staging ✅​

# На staging сервере
cd backend

# Применить baseline
npx prisma migrate deploy

Этап 3: Production ✅​

Критически важно

Production требует максимальной осторожности!

  1. Сделай backup БД перед миграцией
  2. Проверь что baseline миграция точно соответствует текущей схеме
  3. Тестируй на staging сначала
# 1. Backup production БД (обязательно!)
# См. deployment/09-backup-migration.md

# 2. Применить baseline
bash scripts/db/prisma-sync.sh deploy

# 3. Проверить что всё работает (из backend/)
cd backend && npx prisma migrate status
# → Database schema is up to date!

3. Workflow после миграции​

Development​

# Изменил schema.prisma → создать миграцию
npx prisma migrate dev --name add_new_field

# Что происходит:
# 1. Prisma генерирует SQL миграцию
# 2. Применяет к dev БД
# 3. Генерирует Prisma Client
# 4. Запускает seed (опционально)

Staging/Production​

# Просто применить миграции из git (из корня проекта)
bash scripts/db/prisma-sync.sh deploy

# Prisma применит только новые миграции

4. Сравнение команд​

ДействиеPush-based (старое)Migration-based (новое)
Dev: изменил схемуdb pushmigrate dev --name X
Production: deploydb push (⚠️)migrate deploy (✅)
Сброс dev БДdb push --force-resetmigrate reset
Откат изменений❌ Вручнуюgit revert + migrate deploy
Team sync❌ Конфликты✅ Автоматически через git

5. Обновить скрипты​

prisma-sync.sh ✅​

Обновлено: Добавлена команда deploy

# Старое (⚠️):
# bash scripts/db/prisma-sync.sh push

# Новое (✅):
bash scripts/db/prisma-sync.sh deploy

reset-db.sh ✅​

Обновлено: Автоматическая детекция workflow

Скрипт сам определяет:

  • Если есть prisma/migrations/ → migrate reset
  • Если нет → db push --force-reset

Dokploy auto-deploy ✅​

После push в main → автоматически применяются миграции из prisma/migrations/.

Настройка: В Dokploy post-deploy hook:

cd backend && npx prisma migrate deploy
Где настраивается

Post-deploy hook настроен в Dokploy web UI (не в коде репозитория). Для изменения — зайти в Dokploy панель → настройки сервиса → deploy hooks.

6. Rollback миграции​

Важно

Prisma НЕ генерирует обратные миграции автоматически. Для отката необходимо вручную написать reverse SQL или использовать git revert + prisma migrate dev.

# Вариант 1: git revert + новая миграция
git revert <commit-hash>
cd backend && npx prisma migrate dev --name rollback_description

# Вариант 2: ручной reverse SQL
# Написать SQL вручную и применить через migrate deploy
bash scripts/db/prisma-sync.sh deploy

7. Checklist​

  • Создана baseline миграция в dev
  • Baseline миграция закоммичена в git
  • Baseline применена к staging через migrate deploy
  • Backup production БД сделан
  • Baseline применена к production через migrate deploy
  • Обновлён prisma-sync.sh (добавлен deploy)
  • Обновлён reset-db.sh (автодетекция)
  • Обновлена CI/CD (если есть автоматические деплои)
  • Команда проинформирована о новом workflow

8. Troubleshooting​

"Migration is already applied"​

# Пометить миграцию как применённую вручную
npx prisma migrate resolve --applied "MIGRATION_NAME"

"Database schema is not in sync"​

# Просмотреть drift
npx prisma migrate diff \
  --from-schema-datamodel prisma/schema.prisma \
  --to-schema-datasource prisma/schema.prisma

# Создать миграцию для исправления
npx prisma migrate dev --name fix_drift

Production migration failed​

# 1. НЕ ПАНИКОВАТЬ
# 2. Восстановить backup
# См. deployment/09-backup-migration.md

# 3. Исследовать проблему
npx prisma migrate status

# 4. Исправить миграцию
# 5. Попробовать снова