部署從測試到生活的SQL Server數據庫

Question

我想知道你們是如何管理2臺SQL Server之間的數據庫部署的，特別是SQL Server 2005. 現在有一個開發和一個活的。由於這應該是構建腳本的一部分（標準的windows批處理，甚至可以使用這些腳本的當前複雜性，我可能會在以後切換到PowerShell等），Enterprise Manager/Management Studio Express不計算在內。

你會複製.mdf文件並附加它嗎？在處理二進制數據時，我總是會小心一些，因爲這似乎是一個兼容性問題（即使開發和生活應始終運行同一版本的服務器）。

或者 - 由於缺少T-SQL中的「EXPLAIN CREATE TABLE」 - 您是否做了一些將現有數據庫導出到可以在目標服務器上運行的SQL腳本？如果是的話，有沒有一種工具可以自動將給定的數據庫轉儲到SQL查詢中並且在命令行上運行？ （同樣，Enterprise Manager/Management Studio Express不計算在內）。

最後 - 考慮到實時數據庫已經包含數據的事實，部署可能不涉及創建所有表，而是檢查結構和ALTER TABLE中的差異，而不是實時的，這可能還需要數據驗證/轉換現有的領域改變。

現在，我聽到很多關於Red Gate產品的很棒的東西，但對於愛好項目，價格有點陡峭。

那麼，什麼是您使用從測試自動部署SQL Server數據庫的生活嗎？

Answer 1

我已經採取了手動編碼所有的DDL（創建/更改/刪除）語句，將它們添加到我的.sln作爲文本文件，並使用正常的版本控制（使用顛覆，但任何版本控制應該工作） 。這樣，我不僅可以獲得版本控制的好處，而且可以通過dev/stage進行實時更新，這與代碼和數據庫的相同流程 - 標籤，分支等工作完全相同。

否則，我同意展鵬是昂貴的，如果你沒有一個公司買給你。如果你可以讓一家公司爲你購買它，它確實是值得的！

Answer 2

對於我的項目，我將在REd Gate的SQL Compare和Microsoft的Database Publishing Wizard之間進行交替，您可以免費下載 here。

的嚮導是不是一樣光滑如SQL比較或SQL數據比較，但它的伎倆。一個問題是它生成的腳本可能需要重新排列和/或編輯才能一次流動。

在向上的一面，它可以將你的架構和數據是不壞的免費工具。

Answer 3

如果您有公司購買它，Quest Software的Toad內置了這種管理功能。它基本上是一個雙擊操作，用於比較兩個模式並生成一個同步腳本。

他們有最流行的數據庫的版本，當然也包括的SQL Server。

Answer 4

我的工作方式與Karl所做的一樣，保留了所有用於創建和更改表格的SQL腳本，並保留在源代碼管理的文本文件中。事實上，爲了避免有一個腳本檢查實時數據庫，以確定哪些改變運行的問題，我平時的工作是這樣的：

• 在第一個版本，我把一切都檢測到一個SQL腳本中，並將所有表視爲CREATE。這意味着我最終會在測試過程中丟棄和讀取表格，但這在項目的早期階段並不是什麼大問題（因爲無論如何我通常都會竊聽我​​在那個時候使用的數據）。
• 在所有後續版本，我做兩件事情：我提出一個新的文本文件來保存升級SQL腳本，包含只是該版本的改變。而且我對原始文件進行了更改，並創建了新的數據庫腳本。這樣升級只是運行升級腳本，但如果我們必須重新創建數據庫，我們不需要運行100個腳本即可達到此目的。
• 取決於我如何部署數據庫的變化，我也通常把一個版本表中保存數據庫的版本數據庫。然後，不管運行腳本的人決定，運行創建/升級腳本的任何代碼都會使用該版本來確定要運行的內容。

如果你正在從測試移動到生產的一部分是數據，但是如果你想管理結構並且不支付一個漂亮但昂貴的數據庫管理包，真的不是很難。我也發現這是保持你的數據庫心智跟蹤的一個很好的方法。

Answer 5

我同意腳本一切都是最好的方式是什麼，我主張在工作。您應該編寫從數據庫和對象創建到填充查找表的所有內容。

任何你在UI做不但不會轉化（特別是對於改變......沒有那麼多第一次部署），並最終將需要的工具像什麼展鵬提供。

Answer 6

使用SMO/DMO，這是不是太難以生成您的架構的腳本。數據有點更有趣，但仍然可行。

一般情況下，我把「腳本它」的做法，但你可能想繼續沿着這條考慮別的：

• 發展和分期之間的區別，這樣你可以用數據的一個子集開發.. 。我會創建一個工具來簡單地下拉一些生產數據，或者在涉及安全性的地方生成假數據。
• 對於團隊開發，每個數據庫更改都必須在團隊成員之間進行協調。模式和數據更改可以混合在一起，但單個腳本應啓用給定的功能。一旦你的所有功能都準備好了，你就可以將這些功能捆綁在一個SQL文件中，並在生產恢復時運行。
• 一旦您的分段已被清除，您將再次在生產計算機上運行單個SQL文件。

我已經使用了紅門的工具，他們是偉大的工具，但如果你買不起，構建工具和工作這種方式與理想不太遠。

Answer 7

像羅布·艾倫，我使用的SQL比較/數據由展鵬進行比較。我也使用Microsoft的數據庫發佈嚮導。我也有一個我在C＃中編寫的控制檯應用程序，它需要一個sql腳本並在服務器上運行它。這樣，您可以通過命令行或批處理腳本在其中運行帶有「GO」命令的大型腳本。

我使用Microsoft.SqlServer.BatchParser.dll和Microsoft.SqlServer.ConnectionInfo。控制檯應用程序中的dll庫。

Answer 8

我同意將所有內容都保存在源代碼控制中，並手動編寫所有更改。對單個版本的模式更改會進入專門爲該版本創建的腳本文件。所有存儲的特效，視圖等都應該放到單個文件中，並像源代碼管理一樣處理.cs或.aspx。我使用powershell腳本來生成一個大的.sql文件來更新可編程性的東西。

我不喜歡自動化模式更改的應用程序，如新表，新列等。在執行生產版本時，我喜歡通過命令執行更改腳本命令以確保每個都按預期工作。沒有什麼比在生產中運行一個大的變更腳本和獲取錯誤更糟的了，因爲你忘記了一些沒有出現在開發中的細節。

我也瞭解到索引需要像代碼文件一樣處理並放入源代碼控制。

而且你絕對應該有超過2個數據庫 - dev和live。你應該有一個每個人都用於日常開發任務的開發數據庫。然後是一個模擬生產的臨時數據庫，用於進行集成測試。然後，如果可行的話，也許是一個完整的生產副本（從完全備份恢復），所以最後一輪安裝測試與儘可能接近真實情況的東西相反。

Answer 9

不要忘記微軟對此問題的解決方案：Visual Studio 2008 Database Edition。包括用於部署數據庫更改的工具，在用於模式和/或數據更改的數據庫之間產生差異，單元測試和測試數據生成。

這是非常昂貴的，但我用了一段時間的試用版，並認爲它是輝煌的。它使數據庫與任何其他代碼一樣易於使用。

Answer 10

我將所有數據庫創建爲DDL，然後將該DDL包裝到模式維護類中。我可能會首先做各種事情來創建DDL，但從根本上講，我會在代碼中完成所有的架構維護。這也意味着如果你需要做非DDL的東西，那麼你可以編寫程序邏輯並在DDL/DML之間運行它。

我DBS則有它定義了當前版本的表，這樣可以編寫一個相對簡單的測試集：

1. 是否存在DB？如果不創建它。
2. DB是當前版本嗎？如果沒有，則依次運行這些方法，以使模式保持最新（您可能希望提示用戶確認，並且 - 理想情況下 - 在此時執行備份）。

對於單用戶應用程序，我只是在適當的位置運行此應用程序，對於Web應用程序，我們當前鎖定用戶，如果版本不匹配並且有我們運行的獨立架構維護應用程序。對於多用戶，它將取決於特定的環境。

優勢？那麼我有很高的信心，即使用這種方法的應用程序的架構在這些應用程序的所有實例中都是一致的。它不完美，有問題，但它的工作原理...

在團隊環境中開發時存在一些問題，但這或多或少都是給定的！

墨菲我使用的是亞音速的遷移機制

Answer 11

所以我只是在squential以便有2個方法，上下類的DLL。有一個連續的集成/構建腳本鉤入nant，以便我可以自動升級數據庫。

它不是世界上最好的thign，但它擊敗了編寫DDL。

Answer 12

RedGate SqlCompare是一種在我看來的方式。我們定期進行數據庫部署，自從我開始使用該工具以來，我從未回頭過。 非常直觀的界面，最終節省大量時間。

Pro版本也會負責源代碼控制集成的腳本。

Answer 13

我目前正在爲你工作。不僅將SQL Server數據庫從測試部署到現場，還包括從本地 - >集成 - >測試 - >生產的整個過程。那麼，什麼可以讓我輕鬆地每天都是我做NAnt task with Red-Gate SQL Compare。我不是爲RedGate工作，但我不得不說這是個不錯的選擇。

Answer 14

我還爲所有對象和數據維護腳本。對於部署，我寫了這個免費的實用程序 - http://www.sqldart.com。它會讓你重新排序你的腳本文件，並在事務內運行整個腳本。