我们在所有项目中都使用 Azure Blob 存储。在项目的整个生命周期中，Azure 中文件的命名约定会发生变化：有时我们希望重命名容器、删除额外的文件夹和其他清理操作。但是 Azure 不允许轻易重命名，我们必须进行复制删除。
我们还可以在开发过程中在本地更改命名约定。但是我们需要记住在部署新版本时对生产存储进行准确的操作。
同时我们使用实体框架迁移：我们更新了数据库，创建了迁移脚本。然后我们运行“update-database”并更新数据库。部署脚本会自动运行相同的操作：检查生产数据库是否需要更新，并在需要时进行更新。
如果我们可以为 Azure 存储做同样的迁移，那会有什么好处：检查是否已应用所有迁移脚本，执行缺少脚本的进程。容器中的某处保留对最新执行脚本的引用。
这样的事情存在吗？或者我应该继续尝试并尝试自己实现一些东西。
不，这样的功能/行为不存在。请记住，支持 EF 迁移并且是 EF 本身的一部分，而不是数据库！因此，当您谈论 Azure Blob 存储时，它作为一种服务不提供此类功能，就像 SQL Server 本身不提供此类功能一样。
关于是否存在这样的库/代码的问题 - 不，不存在。
不过，您提出了一个非常有趣的问题！
我个人不是“迁移”的忠实粉丝。您可以在开发生命周期的早期阶段执行此操作。但是一旦你进入 GA/Production，你必须非常小心你在做什么。即使是 EF 迁移也可能适用于小型数据库，但您愿意在具有数百万记录生产数据的表的数据库上运行迁移吗？与斑点相同。如果你有 100 或 1000 个 blob 可能没问题。2M Blob 怎么样？您是否真的愿意放置一些可以通过 2M 实体的代码并对其进行一些操作，并将此代码作为构建/部署过程的一部分运行？我不会。