我的團隊正在評估dbdeploy來管理數據庫遷移。根據我的理解，使用遷移需要一些流程規範，即爲每次更改編寫遷移，爲了達到生產，必須從本地升級到開發以測試生產。如何將對生產數據庫所做的模式更改合併到我的遷移管理過程中？
偶爾我們的生產DBA團隊會將架構更改直接轉到生產環境。如果我們編寫新的遷移以對照我們當前的數據庫開發版本進行更改，那麼遷移將永遠不會針對已經包含更改的模式進行測試，直到將遷移部署到生產中。這關係到我。
另一種選擇是直接對基線模式進行更改，然後在所有環境（本地，開發，測試，階段）中重建數據庫。這種方法關係到我，因爲新的模式可能導致一個或多個遷移中斷。
人們目前如何處理這種情況？
可以理解的是，生產模式上的DB更改必須不時發生。這是非常重要的，但必須將這些文件記錄下來並儘快通知開發團隊。用sql執行的純文本以及對受影響的用例/功能和可能的錯誤跟蹤問題的評論將會執行
將活動數據庫抓回到開發中，並將其與開發人員進行比較（模式）也是一個好主意。
我認爲DBA在生產數據庫上唯一可以改變的就是在這裏和那裏添加一個索引並調整一些sprocs - 所有這些都是爲了提高性能。一般來說，對數據庫的所有其他更改可使數據庫架構與應用程序不兼容。
考慮到這一點，實際上應該版本化的唯一東西是sprocs，並且它是DBA的責任，將它們檢入到源代碼管理中。索引變得更加不穩定，實際上可能不包含在遷移腳本中。
我們將生產數據庫的副本在一夜之間恢復到測試服務器上。
這就服務：
我們不重建開發/測試數據庫等，但我們的一些項目是做的。但是，我不確定這樣做的好處，因爲數據庫不是模式和代碼：它也是數據。這與編譯的.net應用程序不同。
在我的商店裏，生產DBA在未經批准的情況下對產品數據庫進行更改（任何更改）都會被解僱。它發生了。