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

Question

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

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

服务器上有一个 cron 脚本，可以将实时数据库的新版本导出并提交到 repo，我在我的开发机器上设置了一个 merge 后 Hook 来更新我的本地数据库，这对于同步方向生产->测试。

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

所以我愿意接受建议。

编辑 :在我了解架构迁移的工作原理之前，我问了这个问题。我现在在我的大部分 Web 开发工作中使用 django，它有一个很棒的迁移模块，称为 South(1.7 版的 django 核心的一部分)。所以大多数 MVC 框架应该有一个迁移模块来处理这个问题。

Answer 1

如果你想对在平面文件中实现的完整数据库进行版本控制，我建议使用 sqlite后端。

如果您的应用程序需要 MySQL(例如某些过程或 View )，那么版本控制数据库操作脚本(例如 CREATE 、 ALTER )和填充脚本(例如 INSERT )并将它们作为构建过程的一部分运行. dbdeploy is a good pattern to follow .

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

十年前，我做了这件事。我有一个小型数据库——十几个表左右。应用程序已经增长。它现在有2000张 table 。把我当作圣诞 future 的鬼魂，警告你远离我所经历的痛苦。

推荐
这个过程理论上很简单:在开发中更改数据库，将这些应用到生产中，完成。现实要困难得多。我将通过示例来解释我的意思...

您是开发团队的一员。您想添加对禁用帐户的支持。除了代码更改之外，您还决定将其实现为数据库中的位字段，如下所示:
ALTER TABLE Account ADD COLUMN disabled BIT(1) DEFAULT 0;
现在就像我上面提到的，你把它放在一个受版本控制的文件中，我们称之为 addDisabledColumnToAccount.sql .您提交 SQL 和代码更改并推送它们。

其他团队成员获取您的更改、应用架构更改并对其进行测试。你们共同决定增加更改的原始范围以支持帐户的状态，而不仅仅是禁用。所以你这样做:

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

并提交您的更改，然后推送。每个人都重新申请这个并且很高兴。你将它 push 你的后备箱(或者你标记为稳定)，它就可以投入生产了。

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

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

还有哪些问题？好吧，开发人员可能会将两个脚本文件命名为相同的东西。所以你必须建立一些标准来防止脚本名称发生冲突。通常，如果脚本名称与某个唯一的问题 ID 相关联，那就可以了。

另一个问题是每个模式更改脚本可能有一个 MySQL 版本、一个 SQLite 版本、一个 Oracle 版本等。您支持的数据库越多，您需要处理的模式更改就越多。在为脚本命名时请记住这一点。类似 addColumnToTable.mysql.sql , addColumnToTable.sqlite.sql ， 等等。

最后，您必须确保在应用相应的代码更改的同时应用架构更改。我的意思是，通常代码和数据库更改是齐头并进的。只要您的部署技术允许您同时应用两者，并且——重要的是——如果有问题，回滚两者 ， 你很厉害。但是这种程度的自动化可能很困难，而且手工操作很容易出错。

总之，git 将帮助您跟踪您的更改，并帮助您协作创建对架构的更改。但由于随着时间的推移处理架构变化的复杂性，它并不是一个特别的部署工具。