Синхронизация базы данных между обновлениями Mercurial

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

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

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

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

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

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

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

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

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