天青：在代码首先迁移登台环境

我有以下安装在Windows Azure中的测试最佳实践：天青：在代码首先迁移登台环境

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

当构建已通过测试验证并准备投入生产时，我们在生产托管服务中启动“暂存”部署，并执行快速烟测试以确保新构建不是完全破碎。临时实例部署的准确位将部署到生产环境中，所以它正在与生产数据库交谈。当升级受到祝福时，我们点击“VIP交换”按钮，并且构建在生产中进行。一切都很好。

数据库模型更改时会出现问题。我已经完成了Code First Migrations的工作。我可以添加新的迁移，使用包管理器控制台在本地应用它们，然后生成SQL脚本以在推送新版本进行测试时升级测试数据库。问题是，使用Code First Migrations和分段/生产部署的最佳做法是什么？当我使用模型更改部署新构建时，它希望找到与其模型相匹配的数据库。但是，如果我将模型更改应用到生产数据库，生产实例会抱怨，因为它的模型不匹配。

我刚刚跳过了分级烟雾测试。我上传到分段，然后更新生产数据库，几乎同时点击“VIP交换”按钮。然后对生产进行抽烟测试。如果某些事情被严重破坏，请“交换VIP”并恢复数据库更改。

有没有更好的方法来做到这一点，或者说是非常多的呢？

谢谢！

来源

2012-07-03 ManicBlowfish

我有同样的问题，祝你好运，我能想到的，现在唯一的事情就是禁用自动“升级到最新的”，或扩大自己的DbMigrator如果有一些区分舞台和制作的方法。最好的办法是定位一个临时数据库，可以允许升级，然后当你交换另一个数据库时......但是因为当你交换时没有什么“事情发生”，我不知道应该如何发生。 – FRoZeN

这是真的破碎。分期和迁移不兼容。在交换之前，无法迁移和预热登台Web服务器。生产Web服务器在迁移应用后立即关闭。我会假设实体框架将能够处理渐进式更改（例如添加一个表）。看起来唯一的方法是使用单独的临时数据库。 –

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

来源

2012-07-04 00:10:49 AvkashChauhan

谢谢。希望有一些我失踪的魔法，但似乎并非如此。 – ManicBlowfish

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

Click here

来源

2015-09-26 17:02:40 aog

天青：在代码首先迁移登台环境

回答

相关问题