我正在寻找一种方法来进行日常部署并使数据库脚本与发布保持一致.
目前,我们有一个相当不错的部署源代码的方式,我们有单位代码覆盖,持续集成和回滚程序.
问题是使数据库脚本与发布保持一致.每个人似乎都尝试在测试数据库上运行脚本,然后在实时运行它们,当ORM映射更新(即更改生效)时,它会选择新列.
第一个问题是没有任何脚本可以写在任何地方,通常每个人都"尝试"将它们放入Subversion文件夹,但是一些懒惰的人只是在现场运行脚本,大多数时候没人知道谁做了什么到数据库.
第二个问题是我们有4个测试数据库,它们总是脱节,真正排列它们的唯一方法是从实时数据库进行恢复.
我非常相信,这样的流程需要简单,直接且易于使用,以帮助开发人员,而不是阻碍他们.
我正在寻找的技术/想法使开发人员想要记录他们的数据库脚本很容易,因此它们可以作为发布过程的一部分运行.开发人员希望遵循的流程.
任何故事,用例甚至链接都会有所帮助.
对于这个问题,我选择使用迁移工具: Migratordotnet.
通过迁移(在任何工具中),您可以使用一个简单的类来执行更改并撤消它们.这是一个例子:
[Migration(62)] public class _62_add_date_created_column : Migration { public void Up() { //add it nullable Database.AddColumn("Customers", new Column("DateCreated", DateTime) ); //seed it with data Database.Execute("update Customers set DateCreated = getdate()"); //add not-null constraint Database.AddNotNullConstraint("Customers", "DateCreated"); } public void Down() { Database.RemoveColumn("Customers", "DateCreated"); } }
此示例显示如何处理易失性更新,例如向具有现有数据的表添加新的非空列.这可以轻松实现自动化,您可以轻松地在不同版本之间上下移动.
这对我们的构建来说是一个非常有价值的补充,并且极大地简化了流程.
我在这里发布了.NET中各种迁移框架的比较:http://benscheirman.com/2008/06/net-database-migration-tool-roundup
阅读K.Scott Allen关于数据库版本控制的系列文章.
我们构建了一个工具,用于根据他描述的技术以受控方式应用数据库脚本,并且运行良好.
然后,这可以用作持续集成过程的一部分,每个测试数据库在对保留数据库升级脚本的URL进行提交时都会对其进行更改.我建议使用基线脚本和升级脚本,以便您始终可以运行一系列脚本以将数据库从其当前版本获取到所需的新状态.
这仍然需要开发人员的一些过程和纪律(所有更改都需要转换为新版本的基本安装脚本和补丁脚本).
我们几年来一直在使用RedGate的SQL Compare:
http://www.red-gate.com/products/index.htm
专业版有一个命令行界面,您可以使用它来设置部署过程.
我们使用K. Scott Allen描述的数据库版本控制的修改版本.我们使用数据库发布向导来创建原始基线脚本.然后是一个基于SQL SMO的自定义C#工具来转储存储过程,视图和用户功能.Red Gate工具生成包含架构和数据更改的更改脚本.所以我们最终得到了像这样的结构
Database\ ObjectScripts\ - contains stored procs, views and user funcs 1-per file \baseline.sql - database snapshot which includes tables and data \sc.01.00.0001.sql - incremental change scripts \sc.01.00.0002.sql \sc.01.00.0003.sql
如有必要,自定义工具会创建数据库,必要时应用baseline.sql,必要时添加SchemaChanges表,并根据SchemaChanges表中的内容根据需要应用更改脚本.每次我们通过cc.net进行部署构建时,该过程都会作为nant构建脚本的一部分发生.
如果有人想要源代码到schemachanger应用程序,我可以把它扔在codeplex/google或任何地方.