2013-07-05 128 views
3

我努力跟上數據庫更改,以及如何從一個發行版到另一個版本乾淨地維護和部署從Dev到PRD的數據庫更改。SQL Server數據庫更改部署

目前,我使用SQL腳本來確定自上次發佈以來發生了哪些變化;

  • 由於我可以簡單地拖放和重新創建存在,因此Procs和Views更容易理解。
  • 表格更改比較困難,因爲現有的表格不能簡單地刪除。

但我認爲我的主要問題是我無法得到我的頭是我們有多個迷你版本發展到任何兩個主要珠三角發佈之間的開發和UAT。

開發人員和UAT迷你版本都可以,只要我從其他開發人員獲得更改列表,然後將其與我的相結合,然後執行發佈,並且我是Dev和UAT DB上的系統管理員,因此我確切地知道那裏有什麼,當我應用這個變化時會發生什麼。

對於珠三角我要準備一個乾淨的腳本,並把它交給了DBA這樣他就可以在那裏,但除了表名,在珠三角列和數據我不能查看任何其他運行它。

這個PRD腳本應該捕捉幾乎所有迷你發行版中的所有內容,但大多數時候這些迷你發行版不是順序的,有時會互相否定,因爲在添加功能A之後,隨後的版本會刪除功能A但對於珠三角我們可能不得不添加功能A,因此不需要第二個小版本,這將有效地刪除特徵A.

所以總之,我正在尋找管理和跟蹤版本之間數據庫更改的方式,也是一個好方法爲DB更改構建部署腳本。

注意:我確實手動保留了TFS中所有SQL對象的副本。

我試過使用數據庫項目,但我沒有得到很多運氣達到我想要的。

任何想法傢伙?任何幫助非常感謝

回答

2

我不熟悉,TFS中,我使用的Git(CVS和SVN以前),因此走在透視這個答案。

管理和版本化SQL位是我噩夢中最糟糕的。 有一些工具可以方便地進行變更管理,紅色的SQL Developer Bundle可以處理比較,並且可以連接到版本控制系統。對於您的請求,您可以使用idera SQL比較工具集,但不應該對idera的完美主義方法進行過分的觀察。

反正在我看來,管理的變化不能,不應該走近因爲它是IT治理的一部分,和程序技術的事情,它需要的文件和任何相關功能之間進行通信。

當一些小型的釋放,熱修復,微變或類似的事情發生,他們在需要得到它的所有其他環境中得到體現。

當然,如果有一個小的釋放在生產,你是UAT的中間,你可能不希望插入該環境中的迷你版本。國際海事組織,在UAT之後不久,您應該將迷你版本應用到環境中,並執行E2E QA會話以確保環境良好。

如果您閱讀我以前的段落,您可能會發現一些問題可以說UAT有SP版本4,而mini-release相同的SP是2 ...您如何確保不會造成迴歸?

這是版本控制系統和合並工具的幫助。紅門工具還應該幫助您構建部署。

但是,我相信治理,溝通和遵守規則是持續成功的最重要因素。

今天的趨勢是實施持續集成,並按需構建測試環境,有內部,託管和雲環境。通常他們並不便宜建立和維護,但他們付出了代價!

最後但並非最不重要的,幾個相同的規則,你應該爲SQL部署進行開發時遵循:在創建過程之前

  1. 每次更改腳本應該是可重複的,例如
    • ,檢查如果它存在,並且插入檢查之前創建
    • 之前將其刪除,該行不存在,然後插入其他更新
  2. 部署到多個數據庫時,每個更改腳本都必須確保您使用正確的數據庫(這裏我發現同義詞是自開罐器創建以來最好的發明之一)
  3. 更改腳本應遵循一個順序。爲每個對象:
    • DDL
    • 應用DCL的DDL上述
    • 應用DML爲表。
  4. 我發現,在腳本的最佳順序是
    • 創建/修改表
    • 創建/修改意見
    • 刷新所有視圖
    • 創建/修改功能
    • 創建/修改功能
    • 執行每個DML。
  5. 在每一個腳本中,爲了避免無法按照ABC的順序排列腳本的子部分,通常你有像FK或SP這樣的執行其他SP的依賴項,這會使得ABC方法令人沮喪。
+0

感謝@Luis的詳細解釋;我認爲這一定是我的錯誤解釋,我無法正確地解決我的問題。我已經在我的部署腳本中遵循了一個序列,如果與您的佈局不同,它也是相似的。但我的主要問題或需要是以編程方式找出所有更改對象,而不是手動計算出已更改的內容。不過,我完全同意你的順序部分。 –

+0

@RobertDinaro看看[Red Gate開發包](http://www.red-gate.com/products/sql-development/sql-developer-bundle/features#SOC),他們有工具來處理版本控制和比較和部署腳本。最有可能的是,他們可以通過編程的方式處理所有更改的對象_部分 –

+0

謝謝@Luis - 這是一個不想花任何錢的公司工作變得更加痛苦:)但感謝您的幫助。非常感激。 –