我在 Windows Azure 中进行了以下设置:
- 连接到自己的“测试”数据库的“测试”托管服务。
- 连接到自己的“生产”数据库的“生产”托管服务。
当构建经过测试验证并准备投入生产时，我们会在生产托管服务中启动“暂存”部署，并进行快速冒烟测试，以确保新构建没有完全损坏。登台实例使用将部署到生产的确切位进行部署，因此它正在与生产数据库进行通信。当登台成功后，我们点击“VIP Swap”按钮，构建就在生产中上线了。一切都很好。
当数据库模型发生变化时，问题就会出现。我的 Code First 迁移工作完美。我可以添加新的迁移，使用包管理器控制台在本地应用它们，然后在推送新版本进行测试时生成 SQL 脚本来升级测试数据库。问题是，使用 Code First 迁移以及临时/生产部署的最佳实践是什么？当我将新构建部署到带有模型更改的暂存区时，它期望找到与其模型匹配的数据库。但是，如果我将模型更改应用到生产数据库，生产实例会提示，因为它的模型不匹配。
我刚刚跳过了分阶段冒烟测试。我上传到暂存，然后更新生产数据库并几乎同时点击“VIP Swap”按钮。然后进行生产冒烟测试。如果某些内容严重损坏，请“交换 VIP”并恢复数据库更改。
是否有更好的方法来做到这一点，或者就是这样？
谢谢!
最佳答案
我不确定什么是最佳实践，因为我找不到任何实践，而且用户似乎正在使用最适合他们的项目并且最适合他们的实践。在一种情况下，解决方案与您所描述的计划类似，其中当生产数据库为空时，首先使用 EF 代码创建临时数据库并应用迁移。测试完成后，脚本将被转移到另一个数据库，该数据库随后与生产连接。
关于entity-framework - Azure:在暂存环境中使用 Code First 迁移进行测试的最佳实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11319577/