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

Question

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

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

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

Как люди в настоящее время обрабатывают этот сценарий?

Answer 1

Мы за одну ночь восстановим копию нашей производственной БД на тестовом сервере.

Это тогда служит:

• В качестве справочной копии (код и данные)
• Мы можем сбросить любые изменения, которые мы сделали
• Мы можем проверить на реальных данных
• Мы можем обеспечить совместимость нового / старого кода
• Мы можем генерировать 100% безопасные сценарии изменения / отката (Red Gate)

Мы не перестраиваем базы данных dev / test и т. Д., Но некоторые наши коллеги-проекты делают. Однако я не уверен в преимуществе, потому что база данных - это не схема и код: это тоже данные. Это отличается от соответствующего .net приложения.

В моем магазине производственный администратор БД, вносящий изменения в БД-продукт (любое изменение вообще) без одобрения, будет уволен. И это случилось.

Answer 2

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

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

Answer 3

Понятно, что изменения БД в производственной схеме должны происходить время от времени. Однако очень важно, чтобы они были задокументированы и сообщены как можно скорее команде разработчиков. Обычный текст с sql, выполненным вместе с комментариями о затронутых случаях использования / функциональных возможностях и возможных проблемах отслеживания ошибок сделал бы

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