mysql-使用git在测试和生产环境之间同步数据库

我正在尝试在php / mysql应用程序的开发过程中实现git.

到目前为止,我已经设置了git repos,并且我们正在使用本地计算机进行测试,并且已经成功地将其用于文件,但是我真的不知道如何处理数据库吗？

服务器上有一个cron脚本,可以将实时数据库的新版本导出并将其提交到存储库,并且我在开发计算机上设置了一个合并后挂钩来更新本地数据库,并且可以很好地同步方向生产->测试.

我不知道如何进行同步.目前,我正在对实时服务器上的数据库进行更改,但是我认为这不是一个好习惯.

因此,我愿意接受建议.

编辑：在我了解架构迁移如何工作之前,我问了这个问题.我现在在大多数Web开发工作中都使用django,它具有一个名为South的出色迁移模块(1.7版django core的一部分).因此,大多数MVC框架应具有一个可解决此问题的迁移模块.

解决方法:

如果要对通过平面文件实现的完整数据库进行版本控制,建议使用sqlite后端.

如果您的应用程序需要MySQL(例如某些过程或视图),则版本控制数据库操作脚本(例如CREATE,ALTER)和填充脚本(例如INSERT),并在构建过程中运行它们. dbdeploy is a good pattern to follow.

更新以评论您的现有程序
本质上,您将生产视为架构的主副本.如果您有多个主控会怎样？当数据库太大而无法有效执行此操作时,会发生什么？如果您需要隔离旧版本代码中的错误,该怎么办？回滚到特定代码/架构状态有多容易？

十年前,我做了这件事.我有一个小的数据库-十几个表.该应用程序已经增长.现在有2000张桌子.让我想起圣诞节前程的幽灵,警告您远离我所经历的痛苦.

建议
从理论上讲,该过程很简单：在开发中进行数据库更改,将其应用于生产中,即可完成.现实要困难得多.我将举例说明我的意思…

您是开发团队的一部分.您要添加对禁用帐户的支持.除了代码更改之外,您还决定将其实现为数据库中的位字段,如下所示：

ALTER TABLE帐户添加列已禁用BIT(1)默认值0;

现在,就像我上面提到的,您将其放在版本控制下的文件中,我们将其称为addDisabledColumnToAccount.sql.您提交SQL,并更改代码并推送它们.

其他团队成员得到您的更改,应用架构更改并进行测试.大家共同决定扩大更改的原始范围,以支持帐户上的状态,而不仅仅是禁用状态.所以你这样做：

ALTER TABLE Account DROP COLUMN disabled;
ALTER TABLE Account ADD COLUMN status ENUM('active','disabled','closed') NOT NULL DEFAULT 'active';

并提交您的更改,然后推送.每个人都重新申请并感到高兴.您将其推入后备箱(或者标记为稳定),即可投入生产.

好.你能发现问题吗？有几种.第一个主要问题是,如果您尝试在生产环境中运行此脚本,它将失败.为什么？因为生产过程中从未添加过“禁用”列.

一般的问题是,开发数据库会经历生产不需要/可能不会经历的临时更改.有很多方法可以解决此问题.我喜欢这样做的方法是保持变更脚本的两个轨迹：开发和生产.开发脚本是累积性的,随着开发的进行会增加更改-生产脚本代表开发的最终结果.它们都使数据库以相同的状态结束,这意味着针对两者中的任何一个的最终测试都应该通过.

还有什么其他问题？好吧,开发人员可能会用相同的名字来命名两个脚本文件.因此,您必须建立一些标准来防止脚本名称冲突.通常,如果脚本名称与某个唯一的问题ID相关联,则可以这样做.

另一个问题是,每个架构更改脚本都可能具有MySQL版本,SQLite版本,Oracle版本等.您支持的数据库越多,则需要处理的架构更改就越多.在命名脚本时,请记住这一点.诸如addColumnToTable.mysql.sql,addColumnToTable.sqlite.sql之类的东西.

最后,您必须确保在应用相应代码更改的同时应用模式更改.我的意思是,通常代码和数据库更改是并行的.只要您的部署技术允许您同时同时应用这两个应用,并且-重要的是-如果有问题都回滚,那么您就很好.但是这种自动化水平可能很难,并且手工完成很容易出错.

总而言之,git将帮助您跟踪更改,并帮助您协作创建对架构的更改.但是,由于处理架构随时间的变化非常复杂,因此它并不是一种特别的部署工具.