我们在tfs2010上有一个asp.Net vb.net 2008项目。该项目有一个主分支,对于任何版本,我们都会创建一个最终部署的新功能分支。后期制作部署我们将分支合并回主分支。
我们现在还添加了一个db项目来管理我们的SQL。问题是如何控制差异脚本的版本。 db项目包含所有创建脚本,如果我们必须从头开始部署p项目但该项目已经存在,那么这很好。所以现在任何新版本或修补程序通常都会包含更改或更改脚本。
如何最好地管理创建脚本和每个版本更改脚本?
答案 0 :(得分:0)
我们多年来一直这样做的方式是使用更新数据库脚本,这些脚本可以将数据库从特定版本更新到另一个版本。
我们应用了两种类型的更新脚本:表更改和数据更改。
表格更改是在制作时手动记录的,其设计方式使得脚本可以安全地对同一数据库多次运行而不会出错。例如,我们只添加一个列,如果它不存在于表中。此方法允许此特定于版本的脚本用于应用修补程序以及从一个版本升级到下一个版本。这些修补程序只是作为文件末尾的附加条目应用。
这种方法需要开发人员纪律,但如果正确实施,我们就能够将4个主要版本和4年过时的数据库更新到当前版本。
对于数据更改,我们使用Red Gate中的工具,特别是SQL Data Compare。
就数据库可编程性(存储过程,触发器等)而言,我们保留一个脚本,在执行时,删除所有当前项,然后重新添加当前版本。通过对所有可编程性元素使用严格的命名约定来启用此过程(存储过程以s_prefix_开头,带有fn_prefix_的函数等)。
为确保应用正确的脚本版本,我们添加了一个小版本表(通常为1行),该表存储在数据库中以记录数据库的当前版本。应用此表时,表更新脚本将更新此表。我们还在脚本中更新此表,该脚本用于从头开始创建数据库。
最后,为了应用脚本,我们创建了一个小工具,用于读取当前版本的数据库,以及一个清单,用于根据当前版本的数据库指定要应用的脚本。
举个例子:
假设我们发布了两个主要版本3和4,则有两个更新脚本,update_v3.sql和update_v4.sql。我们有一个初始结构脚本tables.sql和一个可编程脚本stored_procs.sql。鉴于这些假设,清单看起来像:
tables.sql>当版本= 0时 update_v3.sql>当major_version< = 3时 update_v4.sql>当major_version< = 4时 stored_procs.sql>总是
该工具评估当前版本并按清单中指定的顺序应用脚本,以确保始终以已知方式更新数据库。
希望这有助于您提供一些想法。