5
警告：長問題。你如何版本控制和管理數據庫的多個分支？
[問題]
如果策略是有每個數據庫的分支，如在下面的問題，其中，腳本版本控制說明。
如何在嘗試合併到較少的分支時管理數據遷移問題？
這只是作爲數據遷移的一部分而發生的成本嗎？
必須在遷移時創建基本轉換腳本。
有沒有更好的方法？
我們能同時解決這兩個問題嗎？
什麼是最佳實踐？
[背景]
在我工作的地方，我們有哪些有3個分支的產物。主線有「最新最好」的變化，這是沒有必要準備好發佈。
- 版本B（名稱已更改爲保護有罪）
- 版本A（名稱已更改爲保護有罪）
- 主線
因爲這些部門的有效存在數據庫的3個版本。 代碼版本控制相當簡單，但數據庫版本控制似乎很困難。
閱讀Do you use source control for your database items? 它似乎最好的辦法是導出每個對象/表的所有創建腳本。 注意：根據文章，您如何管理它，在一個大腳本或多個腳本或混合中，是您的首選。
我同意這一點，並詢問爲什麼它沒有完成。
目前，DBA拒絕將腳本分支到分支。 除了懶惰作爲藉口，其原因是爲了節省數據遷移的時間。 實際上，所有版本都強制維護數據庫更改。
所有腳本都受版本控制，只能維護在主線。 版本A和版本B有自己的特殊文件，指出哪些更改腳本在其各自的分支上運行。出現更改腳本時會出現問題，例如應用於版本A，但版本B只需要部分更改。開發人員應該通知DBA更新文件，指出爲每個分支申請哪些補丁。對於手動應用部分更改腳本需要手動干預的更改腳本。
要更新版本A上的數據庫，所有修補程序都將提取版本A的修補程序以應用文件。
[SCENARIO]
- 的3個版本以上存在。
- 數據庫更改發生在版本A上。
- 分支合併，其中代碼從版本B合併到A以便版本B可以被刪除。
- 數據庫也需要這樣做。
希望這是有道理的。
您能否澄清一下您的數據庫腳本是否是當前版本控制的？或者你打算將來使用源代碼控制來維護數據庫的多個分支？另外，你的問題是關於如何頻繁地合併數據庫或者只有一次完全擺脫分支？ – 2009-06-16 03:51:19
我已經澄清了上述問題。似乎版本控制策略已到位僅僅是因爲我無法理解的原因要避免分支。我認爲我對這個問題的理解是因爲數據遷移的成本很高。但是正如John Saunders所說的，當改變腳本首先被創建時，通常會考慮到它。感謝所有幫助的人。 似乎正常版本控制策略畢竟是有效的。 – 2009-06-16 05:13:32