假设我使用自己的（SQL Azure）数据库进行生产和分段部署。如果分段中的模式已更改并且需要部署到生产中，那么在生产数据库中实现数据库升级的定义方式（没有停机时间）？数据库模式更改时的Azure无缝升级
例如如果我交换VIP staging < - >生产（并同时自动更改连接字符串）什么是自动升级sql azure数据库的最佳过程。
我的想法是发现RoleEnvironmentChanging中的环境变化（尽管不知道VIP交换甚至会触发RoleEnvironmentChanginng）并在当时对待即将到来的数据库（即prod）运行sql脚本，但是我需要确保脚本只运行一次，并且会有多个实例转换。
因此，您的生产部署具有自己的SQL Azure数据库和具有自己的SQL Azure数据库的分段部署。在这种情况下，应用程序的连接字符串都指向两个不同的数据库。
你的第一个要求是，当你交换部署或做一些事情来改变运行中的数据库架构和我有与设计以下关注：
如果你写作用的任何代码做“一次且只有一次”行动，并不能保证这只会发生一次。它会发生多时间取决于几个场景如
1.1在你VM需要由系统重新映像任何情况下，该代码将执行完全相同什么它做最后重新映像期间
1.2，您可以保护它不会发生在角色启动或虚拟机启动某些外部键的注册表方法，但有充分的证据机制，不会发生。
因为它，我建议，当你准备要交换的部署，您可以：
2.1运行脚本来更新生产与SQL Azure的架构（这将影响应用程序的下载没有任何影响，因为它没有被触及，但是当你的数据库模式被更新时，你可能会更好地知道它是如何影响你的应用程序的）
2.2更改登台部署中的配置以指向生产SQL Azure（根本不会有任何生产应用程序停机）
2.3 SWAP deplo yment（这也将没有任何应用程序停机时间）
所以即使您手动更新DB模式，然后交换部署有另外的时间采取由DB更新架构没有显著的停机时间。
谢谢你。我认为你在2中的建议是我们将要做的（当然最初）。然而，关于1中的问题，我正在考虑在数据库中使用一个版本表，以便数据库始终知道它在哪个版本，以防止脚本运行两次（事实上，如果我使用EF迁移，我会已经有这个表__MigrationHistory ...嗯）。当然，我必须减少两个同时开始的事件。 – Ian1971
是的，如果你在机器外部使用任何东西，那么它将工作。选项1）只是一个问题，如果你已经使代码依赖于虚拟机本身不会持续的东西。 – AvkashChauhan
我一直在寻找这个遍布全球的最佳实践，但都没有找到。到目前为止，这是我做的：
使用这种方法，我的停机时间约为5分钟;我的数据库很小，这比等待Vm创建和用户获得错误要好。
好问题。我知道的事情（几乎）肯定是：（1）VIP交换不会触发RoleEnvironmentChanging。 （2）更改连接字符串的唯一方法是以编程方式编辑web.config，并将该新连接字符串放在其他地方（？）。 （3）到目前为止连接字符串没有自动更改。这就是为什么我根本不使用登台部署。因此，在服务升级期间，您可能最好承受一些停机时间和/或错误（在升级后通过测试后，将新版本直接升级到生产版本）。 – astaykov