Entity framework 实体框架核心迁移独立的CI/CD管道

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

当前管理迁移的模型是，在两个独立的git存储库中为开发人员提供两个项目

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

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

这种新的体系结构还支持蓝绿色部署，我们的应用程序服务在多个节点上运行

我们面临的问题是，在这种设置下，我们基本上必须手工编写迁移代码，并且不能使用EF Core中提供的任何工具

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

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

有没有办法用EF Core支持这个模型

---

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

我将尝试声称没有，这并不是因为EF Core在某种程度上不支持它，而是因为从我在您的问题中所了解的情况来看，这听起来是不可能的

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

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

因此，我真的不明白在一个单独的存储库中使用单独的管道进行数据库迁移会实现什么。这只会使发布的协调变得复杂，因为它们显然是相互依赖的，但我不认为这有助于解决任何问题。正如您所指出的，您不能将迁移脚本的创建委托给EF Core，至少不需要一些手动工作

---

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

您好。最终，对于我的项目，我不得不坚持使用现有的配置，因为截止日期使我无法完成新的工作。然而，另一位开发人员正在进行一项项目改进，通过将部署迁移的逻辑转移到appservice的发布管道，我们可以使用该工具。本质上，我们可以使用该工具创建迁移，但它们生成的代码将被推送到辅助项目中。然后，当发布管道运行时，它将备份db apply迁移，并在完成后启动b/G部署。在撰写上述文章时，新的发布过程尚未完成，但我们的devops团队仍在进行此工作。