背景： 我們是一個不大的軟體開發團隊，但是客戶遍佈全球 關於資料庫的版本控制前段時間一直沒找到特別好的方式，通過思考和不斷實踐，最近總結了一個不錯的方法，特分享給大家 做好資料庫的版本控制目的： 同時保證：開發--》測試--》客戶基線控制--》數據安全性的需要 1號資料庫（開發）：主要用於開發使用， ...
背景：
我們是一個不大的軟體開發團隊，但是客戶遍佈全球
關於資料庫的版本控制前段時間一直沒找到特別好的方式，通過思考和不斷實踐，最近總結了一個不錯的方法，特分享給大家
做好資料庫的版本控制目的：
同時保證：開發--》測試--》客戶基線控制--》數據安全性的需要
1號資料庫（開發）：主要用於開發使用，所以能持續集成最新的資料庫schema（所有開發人員對資料庫的每日修改都將集成到該資料庫，儘早發現問題）
2號資料庫（客戶測試）：主要用於，和客戶的資料庫同步，客戶升級過程
-
- 獲取客戶的資料庫Schema，放到2號資料庫，並記錄日期和時間，以及版本號
- 比對1號開發資料庫和2號客戶資料庫，生成升級腳本
- 用升級腳本升級2號客戶資料庫，然後進行測試，並修改資料庫名字為新的版本號
- 測試成功，將升級腳本，打包進安裝包，對客戶資料庫進行升級
3號資料庫（基線）：基線資料庫，只保存重大版本的release，比方1.0, 2.0等，小的bug fix 版本都不放基線庫，也就是基本不更新（本人認為更新頻率越低，穩定性和出錯概率越小）。
因為小的bug fix等，這些tracking可以交給TFS或者其它版本控制工具的checkin記錄。
仔細查看，可以發現，其實開發資料庫和基線資料庫在數量上有個1對1的關係
