我正在寻找一种方法来进行日常部署，并使数据库脚本与发行版保持一致.
目前，我们有一个相当不错的方法来部署我们的源代码，我们有单元代码覆盖、持续集成和回滚过程.
问题在于让数据库脚本与发布保持一致.每个人似乎都会在测试数据库上try 该脚本，然后在live上运行它们，当ORM映射更新时(即更改生效)，它会 Select 新列.
第一个问题是，没有脚本必须在任何地方编写，通常每个人都"try "将它们放到Subversion文件夹中，但一些懒惰的人只是在现场运行脚本，大多数时候没有人知道谁对数据库做了什么.
第二个问题是，我们有4个测试数据库，它们总是不符合要求，唯一能让它们真正符合要求的方法是从实时数据库进行恢复.
我非常相信，这样的过程需要简单、直接和易于使用，以便帮助开发人员，而不是阻碍他们.
我要寻找的是一些技术/ idea ，使开发人员能够轻松地记录他们的数据库脚本，以便它们可以作为发布过程的一部分运行.A process that the developer would want to follow
任何故事、用例甚至一个链接都会很有帮助.
对于这个问题，我 Select 使用迁移工具: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");
}
}
这个例子展示了如何处理易失性更新，比如向包含现有数据的表中添加一个新的非空列.这可以很容易地实现自动化，并且您可以很容易地在不同版本之间进行上下转换.
这对我们的构建来说是一个非常有价值的补充，并且简化了流程.
我在文章中比较了各种迁移框架.净收入:http://benscheirman.com/2008/06/net-database-migration-tool-roundup