Блог

Итак, у меня есть среда разработки и производственная среда, которые обращаются к одному и тому же репозиторию BitBucket, и изменения, которые я отправляю в репозиторий, я извлекаю на производственном сервере с помощью hg pull и hg update .

Это поддерживает весь мой PHP-код в актуальном состоянии и работает нормально.

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

Любой совет о том, как это сделать, был бы принят с большой благодарностью.

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

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

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

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

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

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

http://guides.rubyonrails.org/migrations.html

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

Активная запись отслеживает, какие миграции уже были выполнены, поэтому все, что вам нужно сделать, это обновить исходный код и запустить rake db: migrate. Active Record определит, какие миграции следует запускать. Он также обновит ваш файл db / schema.rb в соответствии со структурой вашей базы данных.