Max*_*ero 5 entity-framework ef-core-2.0 entity-framework-migrations
我的公司正在转向微服务，作为这一转变的一部分，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 迁移实现蓝绿部署的首选方法是什么？
我会尝试声称不存在，并不是因为 EF Core 不以某种方式支持它，而是因为根据我在您的问题中的理解，这听起来是不可能的。
您的公司希望能够进行蓝/绿部署，但这只能在服务层上实现，而不能在数据库上实现。这个想法听起来真的很酷，快速回滚，几乎没有停机时间。但实际上，数据库使事情变得更加复杂。
因此，假设您的项目 1 正在计算机 A 和 B 上运行（代表蓝色和绿色部署）。A 当前是生产环境，B 是相同的，但不服务任何 ATM 请求。它们都指向完全相同的数据库（如果不是，则它不是蓝/绿，它只是一个单独的环境）。当您想要部署数据库更改时，您需要迁移数据库，但现在机器 A 和 B 都将指向更新后的数据库。您可以继续从 A 切换到 B，但如果您的数据库迁移破坏了任何内容，它们可能都会停止工作。
因此，我真的不明白通过使用单独的管道将数据库迁移到单独的存储库中会实现什么效果。这只会使版本的协调变得复杂，因为它们显然是相互依赖的，但我不知道它如何帮助解决任何问题。正如您所指出的，您不能将迁移脚本的创建委托给 EF Core，至少在没有一些手动工作的情况下是这样。
很高兴听到这种设计的任何优点。