База данных разработки и производства?

Ответ 1

Каждая среда должна иметь отдельную базу данных. Script все объекты базы данных (таблицы, представления, процедуры и т.д.) и сохраняйте сценарии в исходном элементе управления. Сценарии применяются сначала к базе данных разработки, затем к экзамену (QA, UAT и т.д.), А затем к производству. Применяя одни и те же сценарии к каждой базе данных, все они должны быть одинаковыми в конце.

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

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

Ответ 2

У вас обязательно должно быть два. Чтобы синхронизировать их, вы всегда должны создавать DDL для создания объектов базы данных. Относитесь к этим сценариям, как и код PHP, - держите их в управлении версиями. В любое время, когда вам нужно изменить тестовую базу данных, сделайте script, чтобы это сделать, и проверьте его. Затем вы можете распространять эти изменения в производственной системе, как только будете готовы.

Ответ 3

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

Ответ 4

См. также

Как вы можете изменить схему базы данных?

Это общий вопрос, и его много раз спрашивали и отвечали.

Томас Оуэнс: репликация не используется для схем управления версиями - она ​​предназначена для дублирования данных. Вы никогда не хотите копировать с dev на производство или наоборот.

Ответ 5

После развертывания моей базы данных любые изменения, внесенные в мои базы данных разработки, выполняются в SQL script (а не в инструменте), а script сохраняется и пронумерован.

deploy.001.description.sql
deploy.002.description.sql
deploy.003.description.sql
... etc..

Затем я запускаю каждый из этих сценариев, когда я развертываю.

Затем я архивирую их в каталог под названием

\deploy.YYMMDD\

И начните все сначала.

Если я ошибаюсь, я никогда не вернусь к предыдущему развертыванию script, я создам новый script и поставлю там свое исправление.

Удачи.

Ответ 6

Одна вещь, с которой я работал, - создание виртуальной машины с установленной базой данных. вы можете сохранить виртуальную машину в качестве игрового файла, включая его данные. Тогда вы можете сделать снимок игрового файла и запустить столько разных виртуальных машин, сколько захотите. Они могут быть одинаковыми, или вы можете изменить тот или иной. Здесь хорошая вещь: если у вас есть версия разработчика, которую вы хотите выпустить, вы можете просто запустить эту виртуальную машину на своем производственном сервере вместо текущего сервера.

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

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

Ответ 7

У меня были те же дилеммы. Я застрял, думая, что между production db и t21 существует четкая дихотомия. I. Они были двумя сторонами монеты, и никогда не встречались два.

Многие проблемы исчезли, когда я прекратил делать свое приложение "думать" в терминах "Либо production db ИЛИ development db". Вместо этого мое приложение использует local db.

Когда он работает на моей виртуальной машине (dev), этот локальный db оказывается dev db. Мое приложение действительно не знает об этом.

Итак, для основной части проблема исчезает.

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

Это когда я добавил понятие a live-read-only db connection. Приложение рассматривает это по-разному. Его немного похоже на то, как ваше приложение может обращаться с веб-сервисом, например с Google Apps. Его "некоторый внешний ресурс, который использует ваше приложение".

По умолчанию мое приложение использует local db, а в некоторых особых условиях (в наборе тестов) также используется live-readonly db. (Поскольку его соединение только для чтения, я не боюсь сделать беспорядок живых данных во время тестов).

Чтобы вместо вопроса "dev db ИЛИ production db?", мое приложение спрашивает "local db ИЛИ live-read-only db".

Очевидно, моя ситуация может отличаться от вашей, но я нашел этот "прорыв в понимании" наиболее полезным для меня.