如何為小型 Web 團隊設置本地數據庫開發流程？
背景
我正在為一個由大約 4 名程序員和 4 名設計師組成的小型 Web 團隊創建一個新的開發流程，在未來該團隊具有明顯的發展潛力。我們的產品是一個中央應用程序，為我們設計和託管的客戶網站提供支持。
以前，我們都通過 FTP 在開發伺服器上工作，只有一個開發數據庫。它“工作”了一段時間，但我們正在朝著一個新的方向前進，所以是時候讓我們的流程成熟起來了。
我們使用 Percona Server 5.5，但這應該與數據庫無關，以保持低成本。
目標：
我正在考慮為數據庫開發創建一個持續集成 (CI) 流程，並考慮以下內容：
- 開發人員擁有數據的本地副本來執行開發程式碼
- 能夠將數據庫結構回滾到以前的變更集
- 能夠區分新功能架構更改與架構設計修復更改
- 能夠在本地修改數據庫結構以進行測試
初始概念
我在下面使用 SVN 和 LiquiBase 勾勒出了一個過程，儘管它完全刪除了
#4.
- 從主幹創建一個“開發”分支
- 中央“開發”數據庫伺服器執行“開發”分支
- 本地開發人員被設置為開發分支的奴隸（
#1上面提供）- liquibase 變更集定期送出到開發分支，該分支執行送出後掛鉤以更新中央開發數據庫（這將滲透到作為該開發伺服器的從屬執行的本地電腦）（liquibase 在
#2上面提供）- 當功能或模式修復準備好進行質量檢查時，DBA（我）會將開發分支中的適當更改合併到主幹中。此操作將創建一個 sql 腳本以應用於臨時數據庫伺服器。
- 暫存伺服器應該反映 TRUNK，它應該具有與生產相同的結構，以及 QA 中的更改
- 在登台伺服器上執行 sql 腳本後，對更改進行一些 QA。
- 如果一切看起來都不錯，請標記結構。這將生成由 DBA 手動在生產環境中執行的 .sql 腳本（如果需要，可用於非高峰時段）
此過程要求所有開發人員執行相同的“開發”分支，這意味著在任何給定時間只有一個版本的數據庫模式（不確定我是否想要這個）。
這也意味著對模式的任何更改都無法在本地進行測試，如果操作不當，可能會影響其他開發人員。在我們的環境中，開發人員可能會添加新表，但很少修改現有結構。作為 DBA，設計修復由我完成。但是無法在本地測試修復程序是我對該過程的最大阻礙。
如何調整上述過程以允許本地開發，同時仍保持相對最新的數據副本（由我提議的過程中的複制提供）？我不需要數據是最新的，即使是上週。
*通過“工作”，我的意思是它就足夠了，但它是一個 PITA。
管理環境
我認為您絕對不想被迫使用單個數據庫版本。您擁有足夠多的開發人員，您將不可避免地擁有多個開發工作流，並且要求將更新檔應用到獨立於開發工作流的目前生產環境。
您可以使用 Liquibase 或手動過程來生成更新檔腳本以升級版本。我建議從手動過程開始，並在更新檔上使用模式比較工具進行 QA。對一個非常複雜的數據庫進行乾淨、自動化、透明的同步有點空想。
您的中央數據模型可以保存在您喜歡的任何系統中。我使用了從繁瑣的企業儲存庫工具到創建表腳本的所有東西。創建表腳本可以很好地與普通的原始碼控制工具（例如 subversion）配合使用，並且並非所有儲存庫工具都能很好地進行版本控制。
無論您使用什麼作為主數據模型儲存庫，您都需要一個相當乾淨的機制來從該模型部署環境。它的結構應該使部署到環境很容易。您還需要一種機制來從一個已發布版本修補到下一個版本。
我做了什麼
我過去在管理開發環境時做過以下事情。它不是特別高科技，但它適用於版本控制和自動建構，因此可以輕鬆地將環境部署到特定版本，並且維護大量環境非常實用。
**維護中央儲存庫：**這可以是保存在版本控制系統中的一組數據庫創建腳本，或者是數據建模工具中的儲存庫模型。任你選。這個模型應該有一個建構機制，允許從腳本中推出一個環境，而無需大量的人工干預。
如果您有很多參考數據，您將需要一個載入機制。根據您的操作方式，您可以將其保存在數據庫或一組文件中。文件的優點是它們也可以從與您的程式碼庫相同的版本控制系統進行版本控制和標記。原始碼控制儲存庫中的一堆 CSV 文件和批量載入器腳本可以很容易地做到這一點。
部署開發環境的一種選擇是備份生產數據庫並修補到適當的版本，並讓開發人員可以將它們恢復到開發環境中。
**使其易於部署：**與任何 CI 建構過程一樣，數據庫應該可以通過單個腳本進行部署。設置它以便數據庫連接可以參數化，或者腳本與位置無關並且可以通過連接執行。
**更新檔腳本：**您需要從每個發布的版本前滾和可能回滾腳本。
**從儲存庫模型建構測試環境：**這可確保在與儲存庫不同步的環境上的開發在測試中被擷取。
**測試部署過程：**自動修補腳本，但是它們被創建應該是可測試的。模式比較工具對此非常有用，即使您不使用它們來生成更新檔腳本。
- 使用您測試過的儲存庫模型建構參考環境
- 使用生產版本的備份或基於目前發布版本的建構創建冒煙測試環境。
- 針對冒煙測試環境執行更新檔腳本。
- 使用模式比較工具將冒煙測試環境與參考環境進行比較。更新檔腳本應該導致兩個數據庫相同，因此您可以調查任何差異。
我喜歡這個過程的地方
這有點重量級，旨在部署到相當官僚和不透明的生產環境中。但是，它具有以下優勢：
- 開發人員可以在需要的地方進行修補。
- 可以容納多個分支和開發流。
- 部署腳本本身可以以可重複的方式進行測試。這對於關閉部署混亂非常有幫助，因為可以證明可重複性。
- 架構比較工具提供部署本身的 QA。
- 測試總是針對預期發布的內容進行，這將發現環境不同步引起的問題。
- 基於儲存庫模型和更新檔腳本的部署意味著不受控制的垃圾不會意外地從開發環境遷移到生產環境。
- 儘管通常需要手動準備和測試部署更新檔腳本，但許多過程都可以自動化。
- 環境便宜且易於部署，無需費力。
- 開發人員被迫製作一個適合簡單建構和部署過程的系統。
- 開發人員被迫學習基本的數據庫管理任務，但測試和生產環境不會出現新手錯誤。
它如何滿足您的要求
- 開發人員擁有數據的本地副本來執行開發程式碼
部署腳本或數據庫映像意味著他們可以從任何可用版本設置環境。 2. 能夠將數據庫結構回滾到以前的變更集
，再次按部署腳本排序。通過 DDL 或通過受控過程創建的測試數據庫備份映像，開發人員可以為您擁有的任何特定版本提供環境。 3. 能夠將新功能架構更改與架構設計修復更改
分開 可以在 svn 樹的單獨分支中維護通用版本的更新檔。如果將數據庫備份用作參考環境，則它們需要儲存在與原始碼控制項目的分支具有相同文件夾結構的某個位置。 4. 能夠在本地修改數據庫結構以進行測試
簡單的部署過程允許開發人員進行修補，輕鬆地將環境恢復到本地狀態，或者調出參考環境進行比較並進行更改集。