Entity Framework Core Migrations 独立的 CI/CD 管道

Question

我的公司正在转向微服务，作为这种转变的一部分，devops 正在使用 VSTS 和 GIT 在 Azure 中建立 CI/CD 构建发布管道。

当前管理迁移的模型是开发人员在 2 个独立的 git 存储库中获得 2 个项目。

项目 1 - API 服务项目 - .NET Framework / .Net Core
项目 2 - 使用迁移 API 的基于 EF6 的数据库项目

这些项目具有基于存储库的完全独立的发布管道。因此，当您在 master 中创建拉取请求时，管道会构建并发布项目。

这种新架构还支持蓝绿部署，我们的应用服务在多个节点上运行。

我们遇到的问题是，通过这种设置，我们基本上必须手动编写迁移代码，并且不能使用 EF Core 中提供的任何工具。

我读过的大多数文章和文档都显示了从应用启动时运行迁移，但是如果您有多个应用服务节点，如何防止 2 个节点运行迁移？

我看过的其他文章展示了将迁移移动到一个单独的项目中，但该项目需要引用包含 dbcontext 的项目。在我公司的设置中，这是不可能的。我们也不能反过来做，因为将 dbcontext 移动到数据库项目中会阻止我们在 api 服务项目中引用它。

有什么方法可以用 EF Core 支持这个模型？

在多节点应用服务上使用 EF Core 迁移实现蓝绿色部署的首选方法是什么？

Answer 1

我会尝试声称没有，也不是因为 EF Core 不以某种方式支持它，而是因为根据我在您的问题中的理解，这听起来是不可能的。

您的公司希望能够进行蓝/绿部署，但这只能在服务层实现，而不是在数据库上。这个想法听起来很酷，快速回滚，几乎没有停机时间。但实际上数据库使事情复杂化了很多。

假设您的项目 1 在机器 A 和 B 上运行（代表蓝色和绿色部署）。 A 当前是生产环境，B 是相同的，但不服务于任何请求 ATM。它们都指向完全相同的数据库（如果不是，它不是蓝色/绿色，它只是一个单独的环境）。当您想要部署数据库更改时，您会迁移数据库，但现在机器 A 和 B 都将指向更新后的数据库。您可以继续从 A 切换到 B，但如果您的数据库迁移出现任何问题，它们都可能会停止工作。

因此，我真的不明白通过在具有单独管道的单独存储库中进行数据库迁移可以实现什么。这只是使版本的协调变得复杂，因为它们显然是依赖的，但我看不出它如何有助于解决任何问题。正如您所指出的，您不能将迁移脚本的创建委托给 EF Core，至少在没有一些手动工作的情况下是这样。

很高兴听到这种设计的任何优点。