Работали ли вы с миграциями базы данных в Entity Framework Core?

Да, активно использовал миграции EF Core для управления эволюцией схемы базы данных в процессе разработки и развертывания.

Базовый рабочий процесс:

# 1. Создание миграции после изменения модели
dotnet ef migrations add AddCustomerEmailColumn
# 2. Обновление базы данных до последней миграции
dotnet ef database update
# 3. Генерация SQL-скрипта для применения в продакшене
dotnet ef migrations script --idempotent --output migration.sql

Ключевые практики и нюансы:

1. Структура миграции: Каждая миграция содержит два основных метода в файле <MigrationName>.Designer.cs:

   • Up(): Применяет изменения.
   • Down(): Откатывает изменения.

2. Кастомизация миграций: Автоматически сгенерированный код часто требует ручной доработки.

   // В методе Up() сгенерированной миграции
   protected override void Up(MigrationBuilder migrationBuilder)
   {
       migrationBuilder.AddColumn<string>(
           name: "Email",
           table: "Customers",
           type: "nvarchar(200)",
           maxLength: 200,
           nullable: false,
           defaultValue: ""); // Добавляем значение по умолчанию для существующих строк
       // Можно добавлять индексы, внешние ключи, выполнять сырые SQL
       migrationBuilder.Sql("UPDATE Customers SET Email = 'temp@example.com' WHERE Email IS NULL");
   }

3. Безопасное развертывание в продакшене:

   • Никогда не запускать dotnet ef database update напрямую на продакшен-сервере.
   • Использовать SQL-скрипты: Генерировать скрипт (dotnet ef migrations script) и применять его через инструменты CI/CD (например, Azure DevOps, GitHub Actions) или DBA.
   • Идемпотентные скрипты: Флаг --idempotent генерирует скрипт, который можно безопасно запускать многократно.

4. Работа в команде:

   • Файл миграций (.cs) должен быть закоммичен в систему контроля версий.
   • При конфликтах (два разработчика создали миграции с разными именами) может потребоваться сброс (dotnet ef migrations remove) и пересоздание миграции на основе актуального состояния.

5. Откат (Rollback):

   # Откат на одну миграцию назад
   dotnet ef database update PreviousMigrationName
   # Полный откат всех миграций (осторожно с данными!)
   dotnet ef database update 0

6. Пустые миграции: Иногда создаются для выполнения специфического SQL (например, обновления справочных данных, создания сложных индексов).

   dotnet ef migrations add UpdatePostalCodes --empty