持續集成中的數據庫變更管理

Question

將數據庫變更管理添加到持續集成場景中的最佳方式是什麼？ 我已經閱讀了一些問題和答案，但他們是從2009年開始的，肯定有一些技術和工具是同時開發的。

我正在使用TFS 2010，但那不是重點。我對如何在持續集成的同時管理數據庫更改的概念感興趣。有任何想法嗎？

Answer 1

我建議紅門堆棧SQL來源與比較 - 它絕對可以走很長的路，以具有SQL集成了一個有效的CI環境

Answer 2

我們已經成功地進行數據庫變更管理使用Liquibase。

使用best pratices，您可以定義多個數據庫更新日誌，並在CI服務器（在我們的例子中爲TeamCity）的幫助下保持所有環境爲最新狀態。

Answer 3

除了紅門工具，你也可以嘗試使用ApexSQL Diff和ApexSQL Version來完成同樣的事情。

這些工具都不會出錯，如果您想要第三個選項，您可以查看Idera的工具。

請注意，所有這些都是商業工具，但他們都有14-30天的審判。

Answer 4

我們剛剛發佈了適用於SQL Server的數據庫強制更改管理解決方案（商業解決方案）DBmaestro TeamWork。

它強制執行的版本控制過程的真正的數據庫對象（而不是其與數據庫斷開連接腳本）

它生成的SQL腳本，以促進使用基線感知分析其瞭解這種變化的本質變化例如：更改應該被忽略，因爲它來自不同的分支或關鍵修復，或者存在衝突，您必須合併程序代碼。

免責聲明 - 我在DBmaestro工作。

說了，我會鼓勵你閱讀的數據庫實施管理解決方案由經驗豐富的數據庫專家本·泰勒的全面，公正的回顧，他在LinkedIn https://www.linkedin.com/pulse/article/20140907002729-287832-solve-database-change-mangement-with-dbmaestro

Answer 5

發佈我們有一個新的解決方案，它採用以下的方法：

1. 開發人員腳本單個SQL更改並提交他們來源 控制。
2. 我們的程序（OneScript）從 源控件中提取更改腳本文件，對它們進行過濾和排序，並生成一個單一的 發行腳本文件。 （效果比聽起來好。）
3. 然後，該版本腳本文件應用於 數據庫以進行發佈。

我們的主頁here更詳細地解釋了這個過程。它也有一個鏈接到一個從Subversion鉤子自動執行這些步驟的例子（但是這也可以來自TFS）。在提交之後不久，開發人員會收到一封電子郵件，說明發布是成功還是有錯誤。包含PowerScript代碼。

的想法是，最終您有充分的測試和完全相同的腳本通過移動所有的督促前環境，並最終用於釋放應用於您PROD數據庫釋放腳本。對於公司，使OneScript

免責聲明-I工作。