相关疑难解决方法(0)

我正在使用TFS版本管理来进行持续集成和部署.

我在部署期间使用migrate.exe来执行数据库迁移,当您从旧版本迁移到较新版本时,这非常有用.但是,当您想要部署旧版本的应用程序时,它会变得更加混乱.

基本上,保存上下文迁移的程序集必须知道如何从第3版转到第2版.通常,您使用要部署的程序集作为迁移的源,但在这种情况下,您必须使用已部署的程序集,因为他们是唯一知道如何从v3下载到v2的人.(版本2不知道v3甚至存在.)

我目前的计划是在部署期间以某种方式比较两个程序集.如果安装目录中的程序集包含"部署控制器"中的"更新"迁移,我首先需要在部署目录中的程序集中获取"最新"可用迁移,然后执行:

migrate.exe AssemblyInInstallationDir /targetMigration NewestFromAssemblyInDeploymentDir

在您正在升级到较新版本的"正常"部署方案中,您可以这样做:

migrate.exe AssemblyInDeploymentDir

这是一种合法的做法吗？我还没有考虑使用EF库来评估每个程序集中可用的迁移.还存在这样的事实的挑战:这些组件中的每一个都是"相同"的不同版本.我可能需要将它们加载到单独的应用程序域中,然后使用跨应用程序域通信来获取我需要的信息.

编辑

我创建了一个概念验证应用程序,它允许我列出可用的迁移到同一程序集的两个不同版本.这对整个过程至关重要,所以我认为值得记录.

该应用程序使用反射来加载每个程序集,然后使用System.Data.Entity.Migrations中的DbMigrator类来枚举迁移元数据.迁移的名称以时间戳信息为前缀,从而允许我对它们进行排序并查看哪个程序集包含"更新"的迁移集.

static void Main(string[] args)
{
    const string dllName = "Test.Data.dll";
    var assemblyCurrent = Assembly.LoadFile(Path.Combine(System.Environment.CurrentDirectory, string.Format("Current\\{0}", dllName)));
    var assemblyTarget = Assembly.LoadFile(Path.Combine(System.Environment.CurrentDirectory, string.Format("Target\\{0}", dllName)));

    Console.WriteLine("Curent Version: " + assemblyCurrent.FullName);
    Console.WriteLine("Target Version: " + assemblyTarget.FullName);

    const string contextName = "Test.Data.TestContext";
    const string migrationsNamespace = "Test.Data.Migrations";
    var currentContext = assemblyCurrent.CreateInstance(contextName);
    var targetContext = assemblyTarget.CreateInstance(contextName);

    var currentContextConfig = new DbMigrationsConfiguration
    {
        MigrationsAssembly = assemblyCurrent,
        ContextType = currentContext.GetType(),
        MigrationsNamespace = migrationsNamespace …

我有一项在启动时使用 EF Core 运行时迁移的服务：

var migrator = dbContext.Database.GetService<IMigrator>();
await migrator.MigrateAsync("targetMigration", cancellationToken);

为了生成迁移，我首先更新 DbContext 类，然后执行“dotnet ef migrations add”来生成迁移代码。

迁移发生后，部署的升级可能会自动回滚到以前的版本。例如，如果健康检查或测试失败。在这种情况下，我希望应用程序的先前版本能够自动回滚迁移。我知道 MigrateAsync 可以恢复迁移，但在我当前的工作流程中，迁移代码不会出现在以前版本的代码中，因此我不确定它是否能够恢复迁移。

我可以想到这样的工作流程：

1. 更改 DbContext 并运行“dotnet ef add migration”以生成迁移代码

2. 恢复 DbContext 更改并部署应用程序，以便迁移代码“n”存在，但 MigrateAsync 中的目标迁移和 DbContext 的版本为“n-1”

3. 重新应用 DbContext 更改，将 MigrateAsync 更改为目标迁移“n”，然后部署应用程序

但这似乎很尴尬，我不确定是否有必要，以及是否一定有效。

使用 EF Core 部署代码优先运行时迁移的好策略是什么，这样如果部署了以前的版本，迁移可以自动回滚？