hg pull
因此,我有一个正在访问同一个 BitBucket 存储库的开发和生产环境,并且我将更改推送到存储库,我使用and拉下生产服务器hg update
。
这使我的 PHP 代码保持最新并且工作正常。
但是我可以使用一些建议来使我的 MySQL 模式在两个环境之间保持同步。例如,我经常在需要反映在生产服务器上的开发机器上进行更改。
任何关于如何做到这一点的建议都将非常感激。
简而言之,您要做的是对您的数据库模式进行版本控制,以便它在事情发生变化时与代码保持一致。能够做到这一点的关键部分是能够跟踪对数据库模式的更改,并且还能够跟踪数据库模式的当前状态(即它的版本)
跟踪模式更改的一种方法是手动编写对模式的所有更改的脚本。这些更改脚本本质上是架构版本之间的“差异”。生成这些更改文件的另一种方法是使用可以在两个数据库之间或在数据库和创建脚本之间生成差异的程序。理论上,您应该能够开发一个预提交挂钩脚本,该脚本可以从当前数据库为该工作副本生成更改脚本,并为该工作副本生成先前的数据库,但这不是一项简单的任务。
对数据库进行版本控制后,您现在必须解决将这些更改应用到Update
. 为此,您将需要开发一个更新后挂钩,它可以查看数据库(可能在其中Version
链接到 Mercurial 变更集 Id 的某种表中)并确定需要运行哪些脚本才能获得数据库是最新的。
由于 Mercurial 允许您更新到以前的版本,您要么只需要对数据库进行非破坏性更改,要么根本不允许(在社会意义上或技术意义上)将生产工作副本更新到以前的版本. 无论您如何处理它,执行实际数据库更新的更新后挂钩脚本可能需要足够聪明,以尝试应用它已经应用的数据库更改脚本。
显然有许多问题需要解决,并且需要进行大量测试才能使这一切正常工作,无论如何它都不是为您提供的预构建解决方案,但它应该让您顺利实现自动化数据库更新以使它们与您的代码保持一致。祝你好运!
看一下 Rails 框架。他们使用数据库迁移来操作(甚至创建)数据库。它也与测试和跨开发机器完美集成(对于团队)。它是 Ruby(许多人认为它比 PHP 更可取),因此除非您切换它,否则它不会为您工作,但它可能会为您提供一些关于如何为您的应用程序实现它的想法。
http://guides.rubyonrails.org/migrations.html
迁移是一种以结构化和有组织的方式更改数据库的便捷方式。您可以手动编辑 SQL 片段,但随后您将负责告诉其他开发人员他们需要去运行它们。您还必须跟踪下次部署时需要对生产机器运行哪些更改。
Active Record 跟踪哪些迁移已经运行,所以你所要做的就是更新你的源并运行 rake db:migrate。Active Record 将确定应该运行哪些迁移。它还将更新您的 db/schema.rb 文件以匹配您的数据库的结构。