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

Сегодня мы обсуждали методы развертывания баз данных, у нас было несколько недавних сбоев в нашем текущем процессе и мы видели ситуации, когда мы хотели бы откатить развертывание, но старая версия приложения никогда не тестировалась на соответствие новой версии база данных.

С одной стороны, есть развертывания в стиле миграции, где у вас есть инструкция для версии и инструкция для версии (написаны ли они на SQL или на языке вашего приложения), и ваше приложение знает, к какой версии оно должно добраться.

Это просто, и поскольку мы не будем часто откатываться, разработчики стремятся к простому. Однако при добавлении поля / таблицы возникают риски, и это поле заполняется до отката. Или хуже, когда вы сбрасываете данные, которые были актуальны для предыдущей версии.

С другой стороны, мы можем рассмотреть подход к обновлению, откату, откату, когда откат не так радикальный, как в случае с миграциями. Например, обновление может добавить необнуляемое поле; откат делает его обнуляемым, так что старому приложению все равно; rollforward заполняет пустые поля и делает его снова не обнуляемым.

Он сохраняет данные, но сложен как для кода, так и для тестирования (к сожалению, наших автоматических интеграционных тестов практически не существует, и пока мы исправляем это, у нас пока есть проблема).

Существуют ли безопасные способы смягчения проблем с ними? Есть ли другие варианты, которые я должен рассмотреть? Были ли у вас плохие переживания, которыми вы хотели бы поделиться, которые могут спасти меня от боли позже?

Изменения базы данных должны обрабатываться, как и все другие изменения, и развертываться как сценарии как часть развертывания (и, конечно, сохраняться в системе контроля версий). Поскольку они развернуты с кодом для одной и той же версии приложения, вы точно знаете, что нужно откатить. Вы можете придумать и написать сценарий для отмены каждого изменения во время написания сценария базы данных, но если откаты не распространены, вы можете не захотеть этого делать. Если заполнить новый столбец, вы потеряете данные, если вернетесь в исходную базу данных.

В SQL Server вы можете сделать моментальный снимок непосредственно перед развертыванием, а затем немедленно вернуться к нему в случае сбоя развертывания. Это предполагает, что развертывание не происходит, когда пользователи находятся в системе (вы не хотите терять их изменения данных). Это наиболее полезно во время основного выпуска, когда вам может понадобиться отключить всю систему, чтобы выполнить обновление. Или вы все еще можете сделать снимок и сравнить базу данных между снимком и базой данных, чтобы увидеть различия, если вам нужно выполнить откат. Такой инструмент, как SQLCompare, может даже сгенерировать код, чтобы вернуться к структуре снимка. Я не знаю, что доступно для других баз данных.

Изменения в структуре базы данных должны быть автоматизированы / написаны и протестированы с использованием тестовой среды. Ручные изменения слишком рискованны в производственной среде

Единственная разумная стратегия отката (с наименьшей вероятностью ухудшить ситуацию) - вернуться к моментальному снимку перед обновлением. Если что-то пойдет не так, это произойдет либо достаточно быстро, чтобы сделать возможным возврат к моментальному снимку, либо слишком поздно для отката (следующий отчет на конец недели не будет выполнен из-за проблем в базе данных).

Изменения могут быть сделаны постепенно (например, добавление поля) и, таким образом, протестированы в реальном времени с меньшим риском, чем при выполнении их всех за один проход.

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

Будьте готовы перейти в аварийный режим через несколько дней после обновления базы данных, как если бы это было обновление программного обеспечения.

Не поддавайтесь желанию исправлять проблемы вручную. Используйте свою стратегию на случай непредвиденных обстоятельств (откат, снимок), а затем подумайте, почему что-то пошло не так, прежде чем снова попытаться выполнить обновление.