如何使用分支机构管理中型项目的数据库修订？

Question

在工作中，我们有4个人在几个不同的项目上一起工作。对于每个项目，我们每个都有一个我们工作的本地副本，然后有一个开发，暂存和实时部署，以及我们拥有的任何分支（我们使用subversion）。我们的数据库是MySQL。

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

Answer 1

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

我相信 Rails首先做了。

Java已至少有一个项目。

这是一个 .NET迁移库。

要更改版本，请运行一个简单的脚本，该脚本会逐步执行所有向上或向下版本，以使您获得所需的版本。它的美妙之处在于，您将迁移检查到与应用程序代码相同的源存储库中 - 它们都在一个地方。

也许其他人可以推荐其他迁移库。

干杯。

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

Answer 2

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

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

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

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

我们解决方案中最难的部分是如何将我们分支机构的更新合并到我们的主干中。我们花了一些时间来开发工作流来解决两个开发人员同时尝试将分支与DB更新合并以及如何处理它的可能性。我们最终确定了在版本控制中锁定文件（我们所讨论的文件实际上是一个表格映射软件版本到db版本，这有助于我们的手动管理策略），就像你对一个线程的关键部分和开发人员一样锁是关于他们更新主干的。完成后，其他开发人员将能够锁定，他们有责任对其脚本进行必要的更改，以确保避免预期的版本冲突和其他糟糕的juju。

Answer 3

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

我们在内部组建了一个小实用程序，它通过从目录中的每个修订中获取内容并应用它们来读取目录更改并根据目录的内容构建大型更新脚本。这个概念非常类似于 DBDeploy 工具，我认为它最初来自 Thoughtworks ，因此您可以使用它。它至少可以为您提供一个好的起点，从这一点上您可以定制更直接适合您需求的解决方案。

祝你好运！