数据库和"分支"

Question

我们目前正在开发一个使用数据库的应用程序.

每次我们更新数据库结构时,我们都必须提供一个脚本来将数据库从先前版本更新为当前版本.

因此,数据库当前有一个数字,它给了我们当前版本,然后我们的软件在我们想要使用"旧"数据库时进行更新.

我们遇到的问题是我们有分支机构:

当我们创建一个新的大功能,用户无法使用(并且不包含在发行版中)时,我们会创建一个分支.

主分支(主干)将定期合并,以确保创建早午餐具有最新的错误更正.

这是一些例子:

问题出在我们的更新脚本上.它们从先前版本更新为当前版本,然后更新数据库的版本号.

想象一下,在创建分支时我们有数据库版本17.

然后我们执行分支,并在Trunk DB上进行更改.DB现在版本为18.

然后我们在分支上进行db更改.由于我们知道已有新版本"18",我们创建版本19和更新程序18-> 19.

然后在树枝上合并主干.

在这个时刻,我们可能会有一些永远不会运行的更新程序.

如果有人在合并之前更新了他的数据库,他的数据库将被标记为具有版本19,更新17-> 18将永远不会完成.

我们想要改变这种行为,但我们找不到如何:

我们的约束是:

• 我们无法在同一分支上进行所有更改
• 有时我们只有2个分支,我们只能从主干到功能分支合并,直到功能完成

我们可以做些什么来确保数据库分支之间的连续性？

Answer 1

我认为最简单的方法是使用Ruby-on-rails方法.每个数据库更改都是一个单独的脚本文件,无论多小.每个脚本文件都有编号,当您进行升级时,只需从数据库当前编号到最后一个脚本运行每个脚本.

这在实践中意味着你的数据库版本系统停止v18到v19,并开始是v18.0到v18.01,然后是v18.02等.你发布给客户的内容可能会卷入一个大的v19升级脚本,但随着您的发展,您将进行许多小型升级.

您必须稍微修改它以适用于您的系统,每个脚本都必须重新编号,因为它合并到分支,或者您必须确保升级脚本不是简单地跟踪上一个升级号,而是跟踪每个升级号码,因此当脚本合并时,仍会填充缺少的漏洞.

当您创建发布标记(首先在主干上)时,您还必须将这些小升级汇总到下一个主要数字中,以保持理智.

编辑:所以从根本上说,你首先要摆脱使用升级sdcript从版本到版本的概念.例如,如果您从一个表开始,并且trunk添加了列A并且分支添加了列B,那么您将trunk合并到分支 - 除非分支版本号始终大于trunk的升级脚本,如果随后将trunk合并到分支,则不起作用.因此,您必须废弃适用于开发分支的"版本"的想法.唯一的方法是独立更新每个更改,并单独跟踪每个更改.然后你可以说你需要"最后一个主要版本加上colA plus colB"(诚然,如果你合并了trunk,你可以从trunk获取当前的主要版本,无论是v18还是v19,但你仍然需要单独应用每个分支更新) .

所以你从DB v18的trunk开始.分支并进行更改.然后在以后合并trunk,其中DB位于v19.您仍然需要应用早期的分支更改(或者应该已应用,但如果重新创建数据库,则可能需要编写分支更新脚本,其中包含所有分支更改).请注意,分支根本没有"v20"版本号,并且分支更改不会像在trunk上那样对单个更新脚本进行更改.如果您愿意,可以将您在分支上进行的这些更改作为单个脚本添加(或者自上次主干合并后更改的1个脚本)或多个小脚本.分支完成后,最后一项任务是对分支进行所有数据库更改并将其转换为可应用于主升级程序的脚本,当它合并到主干上时,该脚本将合并到当前的升级脚本和数据库版本号受到了冲击.

有一种替代方案可能适合您,但是当您尝试使用数据更新数据库时,我发现它有点不稳定,有时它无法进行更新,并且必须擦除并重新创建数据库(公平地说,如果我当时使用SQL脚本,可能会发生这种情况).这是使用Visual Studio数据库项目.这会将架构的每个部分存储为文件,因此每个表只有1个脚本.这些将由Visual Studio本身隐藏,它将向您显示设计器而不是脚本,但它们将作为文件存储在版本控制中.VS可以部署项目,如果已​​存在,将尝试升级您的数据库.注意选项,许多默认设置说"删除并创建",而不是使用alter来更新现有表.

这些项目可以生成(主要是机器可读的)SQL脚本用于部署,我们用它们生成这些脚本并将它们交付给不使用VS且只接受SQL的DBA团队.

最后,有Roundhouse这不是我用过的东西,但它可能会帮助你成为新的升级程序"脚本".它是一个免费的项目,我读它比VS DB项目更强大,更容易使用.它是一个数据库版本控制和变更管理工具,与VS集成,并使用SQL脚本.