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

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

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

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

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

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

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

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

Затем я архивирую их в каталог, который называется примерно так:

\deploy.YYMMDD\

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

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

Удачи

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

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

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

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

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

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

Это распространенный вопрос, который задавали и на него много раз отвечали.

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

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

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

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

Так что по большей части проблема исчезает.

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

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

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

Поэтому вместо того, чтобы задавать вопрос «dev dbИЛИ ЖЕproduction db?», Мое приложение спрашивает «local dbИЛИ ЖЕlive-read-only db».

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