翻譯|使用教程|編輯:莫成敏|2020-05-28 15:52:11.070|閱讀 536 次
概述:本文介紹了如何應對由于部署期間進行的各種檢查和測試以及修復而導致的任何數據庫漂移。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
SQL Compare是一款比較和同步SQL Server數據庫結構的工具。現有超過150,000的數據庫管理員、開發人員和測試人員在使用它。當測試本地數據庫,暫存或激活遠程服務器的數據庫時,SQL Compare將分配數據庫的過程自動化。
本文介紹了如何應對由于部署期間進行的各種檢查和測試以及修復而導致的任何數據庫漂移。
想象一下。Deb DBA剛在staging中簽出了一個新版本的數據庫。她突然發現該版本已“漂移”。從版本控制部署的是版本6.3.5,但是自那時以來,遷移腳本似乎有了一些微小但重要的更改。NVARCHAR數據類型必須增加大小以避免被截斷。性能測試中存在一個愚蠢的故障,因為有人弄錯了索引。安全團隊還根據用戶輸入(未使用parameter)發現了一些已執行代碼的問題。他們修復了存儲過程,因為這樣做比解釋過程更容易。有一個討厭的CHECK約束,它會觸發非常好的數據。測試團隊對此進行了處理。當發布通過管道時,他們依次更改遷移腳本。
DBA被告知要發布此版本,因為企業對其包含的新功能有很大的壓力,并且所有參與管道開發的人員都同意,經過一個不穩定的開始之后,現在已經可以了。她是做什么的?這些更改已很好地記錄在腳本中。他們應該處于源代碼控制中。她不能直接訪問源代碼控制系統,只有開發中的Derek可以訪問SQL Compare。
Deb的難題是這個。準備階段的數據庫是候選版本,并且其遷移腳本已準備就緒,經過測試并可以很好地簽出,但該數據庫不再是v6.3.5。在負責任地從登臺發布到生產之前,她需要它成為源代碼控制中的新版本6.3.6。
首先也是最重要的事情是創建一個表示臨時版本的時間點構建腳本。SSMS可以做到這一點,并且默認設置很好。
從SSMS獲取構建腳本
在SSMS的對象瀏覽器窗格上,單擊服務器的“數據庫”項,然后右鍵單擊數據庫的名稱。您會看到一個上下文菜單。找到通向子菜單的“任務”項目。這有一個項目“Generate Scripts…”。單擊此,您將到達腳本編制向導。在介紹性頁面之后,您將看到此內容。
您會看到我輸入了想要作為腳本目標的文件的名稱和位置。有一個“高級”按鈕,可讓您精確指定腳本的使用方式。這有點像向一位過于熱心的咖啡師點咖啡。幸運的是,您可以忽略該按鈕,因為默認設置可以使我們滿意。單擊“下一步”,您將看到以下內容:
您,或者說Deb DBA,現在差不多完成了。Deb現在要做的就是給腳本加注解,以描述誰在哪里做過什么以及在哪里做(她在每個評論中都包含一個#,以便于查找。)然后,她將腳本發送給開發中的Derek。
更新源代碼管理:將更改添加到對象源
下一步是將更改添加到源代碼管理中,為此,我們將使用SQL Compare。
您,或者說Derek,應該創建一個目錄并將構建腳本放入其中。該腳本應該是目錄中的唯一文件。目標是本地GitHub目錄中版本6.3.5的源代碼目錄。請注意:SQL Compare不正式支持使用SSMS構建腳本作為源。您將看到一些警告,指出“忽略了非模式語句”,但是請堅持并單擊“繼續,而不解決錯誤 ”,并且SQL Compare將在源中生成其通常的對象列表,這些對象與目標中的對象不同。
Derek現在可以將檢測到的更改部署到本地GitHub目錄,以更新對象級源,使其版本為6.3.6。他還可以節省6.3.5到6.3.6遷移腳本的初始剪切,該腳本將由SQL Compare強制生成。
在不同的情況下,目標可能是空的源目錄,在這種情況下,Derek在開發系統上將具有有關Staging數據庫當前版本的“參考構建”。
將更改的文件提交到GitHub
我們假設您使用的是Github或Git。盡管開發中的Derek可以以自己的名字來進行更改,但這并不安全,因為人們有一天會忘記這一插曲和怪罪Derek的全部細節。這里的目的是創建一個新版本,由從事Git列出工作的人員作為共同作者。為此,他們的電子郵件應位于配置設置中。
如果Derek知道誰做了什么,則可以作為更改發行版的人來提交。例如,Timothy Tester可能已添加索引。可以Timothy的名義進行這種更改。
Derek Developer現在對Deb進行了批準。現在,由于對遷移腳本的各種更改已在逐步顯現之前已經在階段中進行了有效的測試,因此Deb DBA在發布之前只有一項最終任務。她將遷移腳本中的版本號更改為6.3.6。
結論
可以很高興地假設我們都一如既往地實踐各種有關持續交付手冊的方法。問題是在數據庫應用程序的部署中必須檢查許多因素。我們可以鼓勵所有人“向左移動”,以確保發布候選版本是完美的,但有時我們必須對務實的決定做出反應。SQL Compare很靈活;它可以應對偶發性問題,否則這些問題可能會阻止部署停滯不前。
任何數據庫驅動的應用程序中的協作都應涵蓋整個發行鏈,包括質量保證和操作,以確保單個發行版的復雜性大大降低,發布頻率更高。如果團隊決定通過處理較小的問題而不是延遲發布來減少候選發布者的分類,那么作為團隊成員,我們當然要確保團隊流程能夠足夠靈活地做到這一點。
相關產品推薦:
SQL Prompt:SQL語法提示工具
SQL Toolbelt:Red Gate產品套包
SQL Monitor:SQL Server監控工具
本站文章除注明轉載外,均為本站原創或翻譯。歡迎任何形式的轉載,但請務必注明出處、不得修改原文相關鏈接,如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn
文章轉載自: