Как вы использовали миграции базы данных при работе с кодом?

Миграции — это краеугольный камень практики Database-as-Code. Мы использовали миграции EF Core для гарантии идентичности схемы БД на всех стендах (dev, test, production) и ведения истории изменений.

Рабочий процесс (Development)

1. Изменение модели данных в классах C# (сущностях DbContext).
2. Создание миграции: Эта команда сравнивает текущую модель с состоянием БД и генерирует файлы миграции.

   dotnet ef migrations add AddUserEmailAndCreatedTimestamp
   # Создаст файлы: 20240515120000_AddUserEmailAndCreatedTimestamp.cs

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

   public partial class AddUserEmailAndCreatedTimestamp : Migration
   {
       protected override void Up(MigrationBuilder migrationBuilder)
       {
           migrationBuilder.AddColumn<string>(
               name: "Email",
               table: "Users",
               type: "text",
               nullable: false,
               defaultValue: "");
   
           migrationBuilder.AddColumn<DateTime>(
               name: "CreatedAt",
               table: "Users",
               type: "timestamp with time zone",
               nullable: false,
               defaultValueSql: "NOW()"); // Пример использования SQL-выражения
       }
       // ... метод Down для отката
   }

4. Обновление локальной БД:

   dotnet ef database update

Интеграция в CI/CD (Production) Прямой вызов dotnet ef в production нежелателен. Вместо этого:

• Генерация SQL-скрипта: На этапе сборки создается idempotent-скрипт, который можно проверить.

  dotnet ef migrations script --idempotent --output migrations.sql

• Применение через инструменты БД: Сгенерированный migrations.sql применяется к production-БД с помощью надежных инструментов (например, Flyway, Liquibase, или через пайплайн DevOps с проверкой DBA). Это дает контроль, возможность отката и аудит.

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

• Миграции должны быть обратимыми (Down метод). Это важно для отката неудачных релизов.
• Не редактируйте файлы миграций после того, как они применены к общей БД. Создавайте новую миграцию.
• Для seed-данных используйте отдельные миграции или кастомную логику инициализации, проверяющую наличие данных.
• Всегда тестируйте миграции на копии production-базы перед деплоем.