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

Question

Я работаю с PHP & mySQL. Я, наконец, обрел контроль над исходным кодом, и я вполне доволен всей разработкой (тестированием) v production v repository для части PHP.

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

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

Тогда я перенесите их в каталог с именем что-то вроде

\deploy.YYMMDD\ 

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

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

Успехов

Answer 4

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

Answer 5

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

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

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

Answer 6

Смотрите также

How do you version your database schema?

Это общий вопрос и был задан и ответил много раз.

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

Answer 7

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

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

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

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

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

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

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

Так, а не задавать вопрос "dev dbИЛИproduction db?", Мое приложение запрашивает "local dbИЛИlive-read-only db".

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