通過交換VIP，您可以輕鬆地在Azure管理門戶中的分段和生產環境之間交換兩個部署。在處理服務的分期版本時，我們也希望使用分段數據庫，因此我們不會冒險破壞實際的客戶數據。但是，在交換分段和生產服務之後，現在生產（和以前的分段）部署顯然應該適用於生產數據庫。如何在Azure中設置部署，以便它們根據環境使用不同的數據庫？
所以基本上要使用的數據庫將取決於實例是否在分期或生產環境中運行。有沒有一個很好的方法來實現這一目標？我猜，依靠VIP和硬編碼數據庫切換可能不是最好的想法。
我的建議是停止使用你使用傳統的「臨時環境」爲功能服務的「分期槽」。當我與人們談論Windows Azure時，我強烈建議他們只使用臨時插槽在新部署上線之前抽菸測試新部署。如果他們想要更持久的測試，我們中許多人習慣於擁有內部部署，然後使用單獨的服務，甚至可以使用單獨的訂閱（如果您希望成本透明化，後者非常棒）。所有這一切說，你唯一真正的選擇是有第二個服務配置，它是你在執行VIP交換之前更新的特定生產，或者你編寫了一些代碼，允許服務檢測它在哪個插槽並拉出兩個適當的配置設置。
然而，正如我在第一段所述，我認爲有一個更好的方式來做事。 :)
+1不應將「分段插槽」用於擴展測試。如果應用程序使用SSL，則可能會有一些東西在「臨時插槽」中無法測試，因爲分段URL會使SSL證書無效。 – 2012-04-02 18:45:05
回覆：「我們想要使用一個臨時數據庫的服務的升級版本，工作時也，所以我們不要冒險重挫實際的客戶數據。」沒有內置的方法來做到這一點。
如果你想沒有風險對生產數據進行測試，考慮在另一個Azure的帳戶做這個測試 - 一個甚至沒有進入生產數據庫。然後，當您認爲系統已經過測試並準備就緒時，只需將其放入生產實例旁邊的臨時插槽中即可進行最終的煙霧測試。
我可以做一個VIP交換之前，通過對分期比如一些場景想象的場景，你想也想跑步，但是不想污染的生產數據。爲此，許多公司使用特殊賬戶 - 與這些賬戶相關的數據已知（或標記爲）不是來自真實客戶，因此可以在報告和賬單等中跳過。
回覆：「依託VIP和硬編碼基於數據庫切換可能不是最好的主意，我猜。」如果通過硬編碼，你的意思是從配置文件中讀取它，這可能不是一個壞主意，如果你使用上面提到的方法。我聽說過一些人會用「如果我們處於臨時插槽並在代碼中做了不同的事情」的方法，但我寧願推薦我上面描述的。
在最近發佈的Azure網站中，這裏的故事發生了變化。您現在可以指定任何應用程序設置或連接字符串是「插槽設置」，將其固定到特定插槽。要解決您的問題，您只需在每個插槽中設置連接字符串並注意檢查「插槽設置」。
現在我不太清楚這是否是一種可取的方法。數據庫模式遷移和回滾沒有出爐，我不確定如何正確處理。也只有應用程序設置和連接字符串以這種方式工作，例如，system.net。郵件設置不能被固定到插槽。爲此，您需要更改代碼以從應用設置中獲取郵件服務器信息等，或者使用其他方法。
我認爲這裏的錯誤銷售只是換回的概念，如果有什麼不對的。最好是運行回滾腳本，最壞的情況是恢復數據庫。您似乎從插槽中獲得的是一次性更新所有網站和webjobs。如果你有很多實例，這可能是一個重要的部署時間。當然，如果你沒有數據庫變更，那麼很容易......但是這種情況發生的頻率如何？ – Kinetic 2017-06-03 18:02:17
下面兩個有效的答案。在Azure中進行分段並不是一個真正的測試環境，只有一種方法可以確保在生產之前一切正在運行，並在出現故障時快速返回。在網站上使用或單獨訂閱。 – 2012-04-02 15:10:09