使用連續或自動部署時，如何部署數據庫？

我正在尋求實施Team City和Octopus Deploy以進行CI和按需部署。但是，數據庫部署將變得非常棘手，因爲很多舊的.net應用程序使用了混亂的數據庫。使用連續或自動部署時，如何部署數據庫？

展鵬似乎有一個很好的插件，團隊市，但價格可能會被絆腳石

你用什麼？我很高興執行腳本，但這是我努力的比較方面（即發生了什麼變化）。

來源

2014-03-28 Fran Hoey

我們已經看過RedGate解決方案，幾乎已經達到了相同的結論，但不幸的是，這使我們擺脫了這種路線。

我能想到的唯一事情就是根據您現有的數據庫生成受版本控制的數據庫遷移腳本，然後將其作爲構建過程的一部分執行。如果您在將來查看.NET項目（不使用CMS），可能會考慮使用實體框架代碼進行第一次遷移。

來源

2014-03-28 15:50:10

代碼優先EF對於新項目非常適用，絕對是這樣做的方式。但對於遺留問題，這是一個棘手的問題 –

我記得一直在考慮這個問題，對我來說，似乎有很多信任你必須加入到這種過程中，因爲自動部署到開發或測試服務器不是'因爲數據可能是可替換的......但是自動更新UAT或生產服務器的想法可能會將這些威脅發送到可能負責數據庫的操作團隊的背後，或者至少恢復它如果不是很對。儘管如此，我認爲它的走向，因爲它太容易被數據庫部署腳本所嚇倒了，而這正是事情被遺忘或遺漏的時候。

我似乎記得使用Red Gate的SQL比較和SQL數據比較工具，因爲（我認爲）有一種命令行方式，它可以很好地用於腳本部署過程，比如Team City，CruiseControl .Net等

來源

2014-03-29 06:34:02

我認爲這絕對是一種方式，通過章魚或類似方式部署網站感覺不對，但隨後手動升級數據庫。 –

如果您發現某個新功能中存在重大錯誤，並且您決定要將活動網站恢復到以前的版本，那麼恢復代碼很簡單 - 只需重新部署一些較舊的修訂即可。但是對於數據庫端來說，你必須有回退腳本。在遷移方法（Laravel，RoR）中，這意味着確保「down（）」命令可以安全地使用實際生產數據。此外，將'down'遷移導出爲原始SQL可能有助於手動恢復。 – JustAMartin

使用關係數據庫時，風險和複雜性更多。在一切都是「文檔」的NoSQL數據庫中，我認爲連續部署不是這樣的問題。一些對象將具有「舊」數據結構，直到它們通過新發布的代碼進行更新。在這種情況下，你的代碼需要能夠支持不同的數據結構。無論如何，遺漏的屬性或者具有不同類型的屬性都應該包含在寫得很好的防禦性編碼應用程序中。

我可以看到對生產數據庫運行腳本的風險，CI和持續交付的但問題是，這些腳本將運行在其他環境中測試第一，以消除任何「陷阱」 :-)

當您實際按下按鈕進行部署時，這並不會減少手指交叉和縮小的數量！

來源

2014-03-31 14:32:55 chrishey

現在你在炫耀！不，我們正在使用無聊的舊SQL Server :( –

我們利用名爲RoundhousE的免費工具來處理數據庫更改與我們的項目，它是相當容易與Octopus部署使用它。

我們創造了我們的解決方案一個新的項目，稱爲DatabaseMigration，包括在項目中，我們保持DB變化腳本回旋的文件夾迴旋exe文件，然後拿着八達通怎麼能之前調用PowerShell腳本優勢，期間，和部署後（PreDeploy.ps1，Deploy.ps1和PostDeploy.ps1分別），並增加了一個Deploy.ps1到項目以及在它下面。

$ roundhouse_exe_path =」 \ RH。EXE 「

$ scripts_dir =」 \數據庫\數據庫名「

$ roundhouse_output_dir =」 \輸出」

如果（$ OctopusParameters）{

$ ENV = $ OctopusParameters [ 「RoundhousE.ENV」]

$ DB_SERVER = $ OctopusParameters [ 「SqlServerInstance」]

$ DB_NAME = $ OctopusParameters [ 「數據庫名」]

}否則{

$ ENV = 「LOCAL」

$ DB_SERVER = 「\ SQLEXPRESS」

$ DB_NAME = 「DatabaseName」 }

& $ roundhouse_exe_pa日-s $ DB_SERVER -d $ DB_NAME -f $ scripts_dir --env $ ENV --silent -o> $ roundhouse_output_dir

在那裏，你可以看到我們檢查了傳遞任何章魚變量（參數）在Octopus運行部署腳本時，否則我們會使用一些默認值，然後我們只需調用RoundhousE可執行文件。

然後，您只需將該項目作爲Octopus打包的一部分，然後在Octopus中添加一個步驟來部署該軟件包，並將其作爲每個部署的一部分執行。

來源

2014-03-31 20:02:39

我前一陣子聽說過這個，忘記了一切，聽起來很整潔，我拿它可以告訴我們什麼版本可以升級？ –

是的，你可以指定一個版本number。你可以指定這個數字，或者它可以從你的項目或者xml文件的dll的程序集信息中獲得，如下所示：https://github.com/chucknorris/roundhouse/wiki/Versioning –

讓數據庫部署自動化是一個真正的挑戰，特別是在嘗試執行構建之後，部署許多方法與原生應用程序代碼一樣。

在構建中，一旦部署了很多，就編譯代碼並創建二進制文件，然後在環境中複製它們。從數據庫角度來看，相當於一次生成腳本並在所有環境中執行它們。這種方法不處理從不同分支合併，進程外的變化（生產中的關鍵修復）等...

我知道的作品爲database deployment automation（免責聲明 - 我在DBmaestro工作），因爲我聽到這個我的客戶正在使用構建和按需部署方法。通過這種方法，您可以將數據庫增量腳本構建爲部署（執行）過程的一部分。使用基線感知分析，解決方案知道是否爲更改生成部署腳本或保護目標，不會恢復或暫停，並允許您合併更改並解決衝突。

來源

2014-04-10 14:24:48 Uri

考慮一個簡單的解決方案，我們已經在這個線程成功嘗試 - How to continuously delivery SQL-based app?

免責聲明 - 我在CloudMunch

來源

2014-04-16 11:23:13 Prasanna

工作，我們使用八達通部署和數據庫項目的Visual Studio解決方案。

構建代理使用帶有dacpac文件的octopack創建nuget包，並在裏面發佈配置文件並將其推送到NuGet服務器上。
然後發佈進程利用SqlPackage.exe實用程序爲發佈環境生成更新腳本，並將其作爲工件添加到發行版中。
以前創建的腳本在SQLCMD.exe實用程序的下一步中執行。

創建和執行步驟的這種分離使我們有可能在兩者之間進行手動步驟，以便有人在Live環境上執行腳本之前進行驗證，更不用說，該腳本作爲工件保存在發佈可以隨時在任何時候引用。

會有需求我會提供更多的細節和步驟腳本。

來源

2015-05-14 09:50:40

使用連續或自動部署時，如何部署數據庫？

回答

相關問題