11

在工作中,我们有 4 个人一起在几个不同的项目上工作。对于每个项目,我们每个人都有一个我们正在处理的本地副本,然后有一个开发、登台和实时部署,以及我们拥有的任何分支(我们使用颠覆)。我们的数据库是 MySQL。

所以我的问题是,什么是管理对每个部署(以及开发人员的本地副本)进行了哪些数据库修订的好方法。现在,每个更改都会进入一个文本文件,该文件的名称带有时间戳,并放入项目下的文件夹中。老实说,这不是很好。我需要一个解决方案来帮助跟踪在哪里应用了什么。

4

3 回答 3

8

http://odetocode.com/Blogs/scott/archive/2008/01/30/11702.aspx

上面的博客将我们带到了我们当前的数据库版本控制系统。简而言之,没有更新脚本就不会更改数据库,并且所有更新脚本都在我们的源代码控制存储库中。

我们只管理架构更改,但您也可以/愿意考虑在版本控制中保留您的数据转储;使用 mysqldump 创建此类文件是一项非常简单的练习。

我们的解决方案与博客中介绍的解决方案有一个关键之处:它不是自动化的。我们必须手动应用数据库更新等。虽然这可能会稍微耗时,但它推迟了全自动系统所需的一些工作。然而,我们自动化的一件事是软件中的数据库版本跟踪:这非常简单,它确保我们的软件知道它正在运行的数据库,并且只有在它知道它正在使用的模式时才会运行。

我们解决方案中最困难的部分是如何将来自分支的更新合并到我们的主干中。我们花了一些时间来开发一个工作流来解决两个开发人员同时尝试将分支与数据库更新合并的可能性以及如何处理它。我们最终决定在版本控制中锁定一个文件(对我们来说,有问题的文件实际上是一个表映射软件版本到数据库版本,这有助于我们的手动管理策略),就像你锁定一个线程的关键部分,以及获得锁是关于他们更新后备箱的。完成后,其他开发人员将能够锁定,他们有责任对其脚本进行任何必要的更改,以确保避免预期的版本冲突和其他不良 juju。

于 2008-10-01T02:54:58.770 回答
5

我们将所有数据库脚本(数据和模式/ddl)保存在版本控制中。我们还保留了更改的中央目录。当开发人员对模式/DDL 文件进行更改或添加以某种方式更改数据的脚本时,这些文件将与 SVN 提交号一起添加到目录中。

我们在内部组装了一个小型实用程序,它读取目录更改并通过从目录中的每个修订版中获取内容并应用它们来基于目录的内容构建一个大型更新脚本。这个概念非常类似于DBDeploy工具,我相信它最初来自Thoughtworks,所以你可以使用它。它至少会给你一个很好的起点,从那时起你可以定制一个更直接适合你需求的解决方案。

祝你好运!

于 2008-10-01T03:08:29.097 回答
2

如果您的数据库很好地映射到一组数据访问对象,请考虑使用“迁移”。这个想法是将您的数据模型存储为应用程序代码,其中包含在每个数据库版本中前进和后退的步骤。

我相信Rails 首先做到了

Java至少有一个项目

这是一个.NET 迁移库

要更改版本,您可以运行一个简单的脚本,逐步检查所有向上或向下的版本,以获取您想要的版本。它的美妙之处在于,您可以将迁移检查到与您的应用程序代码相同的源存储库中 - 这一切都在一个地方。

也许其他人可以建议其他迁移库。

干杯。

编辑:另请参阅https://stackoverflow.com/questions/313/net-migrations-engine.NET 数据库迁移工具综述(来自上面的帖子)。

于 2008-10-01T03:53:53.277 回答