Какая стратегия удаления колонки без зависимостей сохраняет обратную совместимость?

Что проверяют

Знаете ли вы паттерн expand/contract и понимаете ли, что во время выката старая и новая версии приложения работают с одной базой одновременно. Следом обычно спрашивают, как это сделать в EF Core, где миграция генерирует DropColumn сама.

Как отвечать

Удаление колонки разносится минимум на два релиза:

• релиз 1, код перестаёт пользоваться колонкой: убираете чтение и запись, колонка остаётся в базе. Если она NOT NULL без значения по умолчанию, её сначала делают nullable или добавляют DEFAULT, иначе INSERT от новой версии упадёт;
• ожидание: все экземпляры обновлены, окно отката прошло, запросов к колонке в Query Store и логах нет;
• релиз 2, удаление: отдельная миграция с DROP COLUMN. Старый код к этому моменту нигде не работает, ломаться нечему.

Деталь EF Core. Если убрать свойство из сущности и выполнить dotnet ef migrations add, миграция сразу сгенерирует DropColumn, и колонка исчезнет в первом же релизе, пока старые экземпляры ещё её читают. Поэтому в первом релизе колонку оставляют в модели как shadow property: modelBuilder.Entity<Order>().Property<string>("LegacyCode"). Второй вариант: убрать DropColumn из миграции руками и написать удаление в следующей.

Даже если у колонки нет зависимостей в схеме, проверьте потребителей вне приложения: отчёты, ETL, соседние сервисы. В SQL Server помогает sys.sql_expression_dependencies, но динамический SQL в чужом коде он не видит. Там же перед удалением нужно снять DEFAULT-ограничение, EF Core делает это сам. Если данные могут понадобиться, выгрузите их заранее: откат на старую версию кода их не вернёт.

Где спотыкаются

Удаляют колонку в том же релизе, где убрали её из кода. При rolling-деплое старые экземпляры тут же падают с «Invalid column name».

Путают удаление с переименованием и предлагают «добавить новую колонку и скопировать данные». Это схема для переименования или смены типа, для удаления она лишняя.

Переименовывают колонку в _old вместо удаления, считая это безопасным. Для старого кода переименование ломает всё так же, как удаление.