Синхронизация базы данных между обновлениями Mercurial
Итак, у меня есть среда разработки и производства, которые обращаются к одному и тому же репозиторию BitBucket, и изменения, которые я отправляю в репозиторий, я снимаю с рабочего сервера с помощью hg pull и hg update.
Это поддерживает мой PHP-код в актуальном состоянии и отлично работает.
Но я мог бы воспользоваться некоторыми советами по синхронизации моих схем MySQL между двумя средами. Например, я довольно часто вношу изменения в машину разработки, которые мне нужно отразить в производстве сервер.
Любые советы о том, как это сделать, будут приняты с большой благодарностью.
2 answers
В двух словах, вы пытаетесь изменить свою схему базы данных, чтобы она соответствовала коду по мере изменения ситуации. Важнейшей частью возможности сделать это является возможность отслеживать изменения в схеме БД, а также возможность отслеживать текущее состояние схемы БД (т. Е. в какой версии он находится)
Одним из способов отслеживания изменений в схеме было бы вручную написать сценарий всех изменений в схеме. Эти сценарии изменений, по сути, являются вашими "различиями" между версии схемы. Другим способом создания этих файлов изменений было бы использование программы, которая может генерировать разницу между двумя базами данных или между базой данных и сценарием создания. Теоретически, вы должны быть в состоянии разработать сценарий предварительной фиксации, который может генерировать сценарий изменения из текущей базы данных для этой рабочей копии и предыдущей базы данных для этой рабочей копии, но это не тривиальная задача.
Как только ваша БД будет версирована, теперь вам нужно решить проблему о применении этих изменений к Update. Для этого вам нужно будет разработать хук после обновления, который может просматривать базу данных (возможно, в какой-то таблице Version внутри нее, которая ссылается на идентификатор набора изменений Mercurial) и определять, какие сценарии необходимо запустить, чтобы обновить базу данных.
Поскольку Mercurial позволяет вам обновляться до предыдущей версии, вам придется либо вносить только неразрушающие изменения в свою базу данных, либо просто не разрешать (в социальном смысле или техническом смысле) производственная рабочая копия, подлежащая обновлению до предыдущих версий. Независимо от того, как вы с этим справляетесь, сценарий подключения после обновления, который выполняет фактические обновления БД, вероятно, должен быть достаточно умен, чтобы попытаться применить сценарии изменения БД, которые он уже применил.
Очевидно, что необходимо решить ряд проблем и провести множество тестов, чтобы все это заработало, и это ни в коем случае не является готовым решением для вас, но оно должно помочь вам на пути к автоматизации обновлений вашей БД до держите их в соответствии с вашим кодом. Удачи!
Взгляните на каркас Rails. Они используют миграции баз данных для управления (даже создания) базой данных. Он отлично интегрируется как с тестированием, так и с машинами разработки (для команд). Это Ruby (который многие считают предпочтительнее PHP), поэтому он не будет работать для вас, если вы не переключитесь, но это может дать вам некоторые идеи о том, как реализовать это для вашего приложения.
Http://guides.rubyonrails.org/migrations.html
Миграции - это удобный способ для вас чтобы изменить вашу базу данных структурированным и организованным образом. Вы можете редактировать фрагменты SQL вручную , но тогда вы будете нести ответственность за то, чтобы сообщить другим разработчикам, что им нужно пойти и запустить их. Вам также придется отслеживать, какие изменения необходимо запустить на рабочих машинах при следующем развертывании.
Активная запись отслеживает, какие миграции уже запущены, поэтому все, что вам нужно сделать, это обновить исходный код и запустить rake db: migrate. Активная запись определит , какие миграции следует запускать. Он также обновит ваш файл db/schema.rb в соответствии со структурой вашей базы данных.