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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

Это затем служит:

• В качестве референсной копии (код и данные)
• Мы можем сбросить любые изменения, которые мы сделали
• Мы можем проверить на реальных данных
• Мы можем сторону by side new/old code preformance
• Мы можем генерировать 100% безопасные сценарии изменения/отката (красные ворота)

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

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