#sql #sql-server #database
#sql #sql-сервер #База данных
Вопрос:
Я ищу информацию о лучших практиках, касающихся сценариев базы данных для модификаций, которые выполняются параллельно с другими изменениями кода для программной системы.
Раньше я работал в компании, которая настаивала на том, чтобы при каждом развертывании был готов откат в случае возникновения проблем. Это звучит разумно, но, на мой взгляд, код отката для изменений базы данных, развернутых с помощью сценариев, имеет ту же вероятность сбоя, что и сценарий развертывания.
Для управляемого кода управление версиями делает это довольно простым, но для схемы базы данных откат изменений не так прост — особенно если данные изменены в рамках развертывания.
Моя текущая практика заключается в тестировании кода развертывания путем запуска с тестовой базой данных на поздней стадии разработки, а затем запуска приложения с этой тестовой базой данных. После этого я создаю резервную копию действующей базы данных и продолжаю развертывание.
Мне еще предстоит столкнуться с проблемой, но мне интересно, как другие магазины управляют изменениями базы данных и какова стратегия восстановления после любых ошибок.
Ответ №1:
Все наши скрипты базы данных проходят несколько этапов тестирования с базами данных, которые похожи на нашу действующую базу данных. Таким образом, мы можем быть достаточно уверены, что сценарии модификации будут работать должным образом.
Для отката хранимых процедур, представлений, функций, триггеров, всего программного легко откатить, просто примените предыдущую версию объекта.
Как вы упомянули, сложная часть возникает при обновлении / удалении записей из таблиц или даже при добавлении новых столбцов в таблицы. И вы правы в том, что в этом случае откат с такой же вероятностью может завершиться неудачей.
Что мы делаем, если у нас есть изменение, которое не может быть легко отменено, но является чувствительным / критическим разделом… заключается в том, что у нас есть набор сценариев отката, которые также проходят через те же среды тестирования. Мы запускаем сценарий обновления, проверяем, что он работает должным образом, а затем запускаем сценарий отката и проверяем, что он работает так, как это было до модификации.
Еще одна вещь, которую мы делаем просто в качестве меры предосторожности, — это создание моментального снимка базы данных (SQL Server 2005) перед обновлением. Таким образом, если возникнут какие-либо непредвиденные проблемы, мы можем использовать снимок для восстановления любых данных, которые были потенциально потеряны во время обновления.
Таким образом, самый безопасный способ действий — протестировать базы данных, которые находятся как можно ближе к вашей действующей системе, а также протестировать ваши сценарии отката … и на всякий случай, если оба они завершатся неудачей, подготовьте снимок на всякий случай, если он вам понадобится.
Комментарии:
1. Спасибо, это подтвердило большую часть моего опыта. Похоже, мой интернет-магазин (и проект) немного меньше вашего, поэтому тестирование в том объеме, в котором вы занимаетесь, немного выходит за рамки моих бюджетных ограничений, но некоторые хорошие механизмы есть.
Ответ №2:
SQL Diff (или что-то подобное, это всегда полезно, если вы используете тестовую базу данных. В нем много проверок и противовесов, мер предосторожности и способов восстановления или отката в случае возникновения проблемы. Очень полезно.