我有兩個Azure網站設置 - 一個爲客戶端應用程序提供無數據庫服務，另一個提供數據庫和WebApi解決方案，客戶端從中獲取數據。Azure網站遷移和併發
我即將向數據庫添加一個新表，並使用我僅計劃運行一次的臨時Seed方法填充數據。但我不確定最好的方法是什麼。
現在我將數據庫初始化程序設置爲MigrateDatabaseToLatestVersion，我已經多次在本地測試此更新。一切似乎都不錯，但更新/種子方法需要大約6分鐘才能運行。我在遷移時遇到一些關於併發性的問題：
當某人在這個6分鐘窗口中更新業務邏輯和表時正在對數據庫執行CRUD操作時會發生什麼？我的意思是 - 從VS打出「發佈」到實際部署新位之間的時間。如果種子方法修改了另一個表中的每個條目，並且用戶添加了一些不受此重要更新命中的中間種子數據？我應該鎖定網站，以防萬一（遠離理想......）？
關於這個過程的任何一般指導都很棒。
像創建一個新表或添加新列的操作應該只對性能產生最小的影響並且是透明的，特別是當應用程序應用推薦的處理瞬態故障的模式時（例如通過利用Enterprise Library）。
大量更新或重新索引可能會導致爭用並影響應用程序的性能甚至導致錯誤。根據情況，瞬態故障處理也可以解決這個問題。
對正在升級的數據進行並行修改可能會導致難以處理的問題。這些都是一些可能的方案：
維護窗口
最簡單，最安全的方法是將應用程序脫機，備份數據庫，升級數據庫，更新應用，測試和使應用程序重新聯機。
只讀模式
此方法可避免使應用程序完全不可用，通過網上保持，但禁止改變數據庫的任何功能。用戶仍然可以在應用程序更新時查詢和查看數據。
分階段升級
這種方法是基於更改了數據庫結構和數據，並在應用程序代碼的精心策劃序列，以便在任何給定階段的應用程序版本，在線與當前兼容數據庫結構。
例如，假設我們需要在客戶記錄中引入「上次購買日期」字段。可以使用此序列：
這種方法有幾種變化，例如Zero-Downtime Database Deployment中描述的「擴展腳本」和「收縮腳本」的概念。這可以與feature toggles一起使用，以隨着升級階段的執行而改變應用程序的行爲。
可以將新列添加到記錄以表明它們已被轉換。應用程序邏輯可以適用於同時處理舊版本和新版本中的記錄。
實體框架可能會在選項中施加一些額外的限制，因爲它代表應用程序生成SQL語句，因此在規劃階段時必須考慮這一點。
臨時環境
更改生產數據庫結構和執行質量數據的變化是有風險的業務，特別是當它必須在一個特定的順序進行，而正在進入並改變數據的用戶。你的選擇來回復錯誤可能受到嚴重限制。
在執行生產環境的升級過程之前，有必要在單獨的臨時環境中進行大量測試和模擬。
我同意費爾南多的維護窗口的想法。但是，這是我給你的問題的方法。
最重要的是通過Entity Framework使用種子方法，它很容易讓它錯誤，沒有一個適當的備份，而運行反Prod你可以讓你自己陷入麻煩真快。我可能會首先運行它通過測試數據庫/環境（如果有的話）來驗證你想要發生的事情。