在工作中,我们有4个人在几个不同的项目上一起工作.对于每个项目,我们每个都有一个我们工作的本地副本,然后有一个开发,暂存和实时部署,以及我们拥有的任何分支(我们使用subversion).我们的数据库是MySQL.
所以我的问题是,管理每个部署(以及开发人员本地副本)对数据库进行哪些修订的好方法是什么.现在,每个更改都会进入一个文本文件,该文件在名称中加上时间戳并放入项目下的文件夹中.说实话,这并不是很好.我需要一个能够帮助跟踪所应用内容的解决方案.
http://odetocode.com/Blogs/scott/archive/2008/01/30/11702.aspx
以上博客将我们带到了当前的数据库版本控制系统.简而言之,没有更新脚本就不会进行数据库更改,所有更新脚本都在我们的源代码控制存储库中.
我们只管理架构更改,但您也可能/愿意考虑在版本控制中保留数据转储; 使用mysqldump创建这样的文件是一项非常简单的练习.
我们的解决方案与博客中以一种关键方式呈现的解决方案不同:它不是自动化的.我们必须手动应用数据库更新等.虽然这可能会耗费一些时间,但它推迟了全自动系统所需的一些工作量.然而,我们自动完成的一件事是软件中的db版本跟踪:这非常简单,它确保我们的软件知道它正在运行的数据库,并且只有在知道它正在使用的架构时才会运行.
我们解决方案中最难的部分是如何将我们分支机构的更新合并到我们的主干中.我们花了一些时间来开发工作流来解决两个开发人员同时尝试将分支与DB更新合并以及如何处理它的可能性.我们最终确定了在版本控制中锁定文件(我们所讨论的文件实际上是一个表格映射软件版本到db版本,这有助于我们的手动管理策略),就像你对一个线程的关键部分和开发人员一样锁是关于他们更新主干的.完成后,其他开发人员将能够锁定,他们有责任对其脚本进行必要的更改,以确保避免预期的版本冲突和其他糟糕的juju.
我们将所有数据库脚本(数据和架构/ ddl)保留在版本控制中.我们还保留了变更的中央目录.当开发人员更改架构/ DDL文件或添加以某种方式更改数据的脚本时,这些文件将与SVN提交编号一起添加到目录中.
我们在内部组建了一个小实用程序,它通过从目录中的每个修订中获取内容并应用它们来读取目录更改并根据目录的内容构建大型更新脚本.这个概念是非常相似的DBDeploy工具,我相信最初来自ThoughtWorks的,所以你可以利用它.它至少可以为您提供一个好的起点,从这一点上您可以自定义更直接适合您需求的解决方案.
祝你好运!