13

我在 Windows Azure 中有以下设置：

  • 连接到自己的“测试”数据库的“测试”托管服务。
  • 连接到自己的“生产”数据库的“生产”托管服务。

当构建在测试中得到验证并准备好投入生产时，我们在生产托管服务中启动“暂存”部署，并进行快速冒烟测试以确保新构建没有完全损坏。暂存实例使用将部署到生产环境的确切位进行部署，因此它与生产数据库通信。当登台成功时，我们点击“VIP 交换”按钮，构建就可以投入生产了。一切都很好。

当数据库模型发生变化时，问题就出现了。我的 Code First 迁移工作完美。我可以添加新的迁移，使用包管理器控制台在本地应用它们，然后在我推送新构建进行测试时生成 SQL 脚本来升级测试数据库。问题是，将 Code First 迁移与暂存/生产部署一起使用的最佳实践是什么？当我部署一个新的构建以进行模型更改时，它希望找到一个与其模型匹配的数据库。但是，如果我将模型更改应用于生产数据库，生产实例会抱怨，因为它的模型不匹配。

我刚刚跳过了分期烟雾测试。我上传到登台，然后更新生产数据库并几乎同时点击“VIP交换”按钮。然后在生产中进行冒烟测试。如果某些东西严重损坏，请“交换 VIP”并恢复数据库更改。

有没有更好的方法来做到这一点，还是差不多？

谢谢！

4

2 回答 2

0

我不确定什么是最佳做法，因为我找不到任何东西，而且似乎用户正在使用最适合他们的项目并为他们工作的东西。在一种情况下，该解决方案类似于您在其中描述的计划，其中生产数据库为空且暂存数据库首先使用 EF 代码创建并应用迁移。测试完成后，脚本被转移到另一个数据库，该数据库后来与生产连接。

于 2012-07-04T00:10:49.073 回答
0

我一直在研究 Azure、EF 等以及与您类似的主题。我不知道目前您的方案的最佳做法是什么。但是，我相信使用 TFS 和/或 Github 的持续集成工具可以最大程度地降低部署风险。我希望下面的文章能给你一个观点。

点击这里

祝你好运

于 2015-09-26T17:02:40.700 回答