使用OrmLite时,有哪些推荐的模式可用于管理生产部署?

时间:2015-10-26 01:23:07

标签: servicestack ormlite-servicestack

我们目前正在使用带有Entity Framework的ServiceStack,正在调查迁移到ServiceStack.OrmLite。

我们遇到的一个主要问题是如何最好地管理生产部署。

我们使用AppVeyor / Octopus进行持续部署。使用纯代码优先EF,我们可以使用迁移。使用DB-first方法,我们使用了DB Projects,SSDT& MsDeploy或像DbUp这样的工具。但是对于OrmLite,我们不确定最顺畅的设置是什么来处理我们的测试,升级和放大的部署。生产DB分别。我们应该首先采用代码并推出自己的迁移逻辑吗?我们应该首先使用DB并使用T4模板生成POCO吗?

我很想听听那些在持续部署设置中有效使用OrmLite的人的成功故事。

1 个答案:

答案 0 :(得分:2)

虽然粗略的方法,我最近处理模式迁移的方式是将所有迁移保留在我在部署之前手动运行的测试夹具中,这只是使用OrmLite执行自定义SQL DDL语句来修改表模式或填充任何表格数据。

要在环境之间切换,我只需取消注释我想要运行它的环境,例如这是我的DatabaseMigrations测试类的示例:

[TestFixture, Explicit]
public class DatabaseMigrations
{
    IDbConnectionFactory LocalDbFactory = ...;
    IDbConnectionFactory TestDbFactory = ...;
    IDbConnectionFactory LiveDbFactory = ...;

    private IDbConnection Db;

    public DatabaseMigrations()
    {
        //DbFactory = LocalDbFactory;
        //DbFactory = TestDbFactory;
        DbFactory = LiveDbFactory;
        Db = DbFactory.Open();
    }

    //...

    [Test]
    public void Add_ExternalRef_to_Subscription()
    {
        Db.ExecuteNonQuery("ALTER TABLE subscription ADD COLUMN external_ref text");

        var subIds = Db.Column<int>(Db.From<Subscription>().Where(
            x => x.ExternalRef == null).Select(x => x.Id));

        foreach (var subId in subIds)
        {
            Db.UpdateOnly(new Subscription { 
                    ExternalRef = Guid.NewGuid().ToString("N") 
                },
                where: x => x.Id == subId,
                onlyFields: x => new { x.ExternalRef });
        }
    }
}

它不支持回滚,但它可以快速轻松地创建并在源代码管理中按顺序保留所有架构更改并在代码中运行。

使用自定义迁移表定制解决方案

我以前成功使用的其他自定义迁移解决方案涉及在RDBMS中维护自定义表的定制解决方案,例如Migrations,其中包含已在该数据库上运行的所有迁移的列表。 CI任务会将数据库中的行与本地文件夹中的文件进行比较,例如:

/Migrations
    01_Add_ExternalRef_to_Subscription.sql       

并自动运行任何缺少的自定义sql迁移脚本。这种方法在保持RDBMS表与迁移脚本同步方面做得很好,其中每个db上运行的迁移的状态保存在DB本身中。

此解决方案的主要缺点是迁移保留在自定义.sql文件中,这些文件缺乏适当编程语言的灵活性。

最佳解决方案

我认为理想的解决方案是这些方法的组合,即自定义数据库迁移表,而是运行C#DB迁移NUnit测试。数据库连接设置还需要移出外部配置,并可能包含用于回滚模式迁移的解决方案(例如,以&#39; _Rollback&#39;结尾的测试),尽管我需要的次数很少回滚,在需要时手动回滚然后必须为每个已完成的模式更改维护回滚脚本的工作量减少。