翻譯|使用教程|編輯:楊鵬連|2020-07-08 11:01:08.437|閱讀 257 次
概述:本文介紹了所有這些任務,并演示了使用SQL Compare可以實現的功能。在隨后的文章中,我將顯示任務槽到自動SQL Change Automation過程中。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
SQL Compare是一款比較和同步SQL Server數據庫結構的工具。現有超過150,000的數據庫管理員、開發人員和測試人員在使用它。當測試本地數據庫,暫存或激活遠程服務器的數據庫時,SQL Compare將分配數據庫的過程自動化。
數據庫開發永遠不會是一個容易的過程,但是如果給數據庫指定版本號,那么很多人的工作就會變得更輕松,您可以通過一種簡單的方法來驗證是否始終可以構建數據庫以及每個版本的來源源代碼中保留了將遷移腳本從上一個版本遷移到下一個版本的功能。開發工作是一個團隊過程,所有內容都必須可見且可重復。
數據庫版本和版本管理
無論以何種方式完成數據庫的開發工作,開發團隊都將在某個時候確定發布該數據庫的版本。此版本將由版本控制中的腳本表示。經過適當的單元和集成測試后,數據庫的版本將成為候選版本。為什么使用“候選人”一詞?因為它可能無法通過部署管道一直到生產的一個或多個后續測試或檢查。
一旦某個版本成為發行候選版本,就必須保護它不受任何修改,否則后續測試將無效。任何自動化的DevOps流程都需要能夠檢查其是否使用了正確的未更改版本。該版本在數據庫中的明顯位置是將其作為擴展屬性附加到數據庫。最好根據源代碼管理或NuGet包中版本的副本進行檢查。
那么,這些DevOps流程是什么?一旦開發數據庫構建成為候選版本,它將進入通常稱為“部署管道”的過程。這是一個錯誤的稱呼,因為它意味著每次檢查都必須順序進行。實際上,最好并行進行。必須以多種方式測試候選發布版,以確保其足夠健壯,合法,能夠滿足客戶的期望以及滿足客戶的需求。除了通常對每個構建進行的單元和集成測試之外,檢查所有這些內容還涉及非常不同的測試范圍。完成所有這些檢查之后,數據庫就可以進行登臺了。如果它可以分階段通過所有測試,那是可以合法測試真實數據的少數幾個地方之一,那么就可以放心地將其發布到生產環境中。
從我所說的內容中,您會注意到,如果不進行仔細的管理,此發布過程可能會變成“痛苦的世界”。許多數據庫需要與候選版本相同。測試單元還可以包括數據庫的先前版本。我經歷過開發站點,這些站點有多個版本,而其他地方根本不存在。
您已經進行了用戶驗收測試,不僅必須存在運行數據庫及其關聯的應用程序,而且還要協調所有工作并以正確的版本進行操作。然后是暫存,在此您再次需要當前的暫存數據庫服務器來將候選發布以及生產數據放置到位。如果此過程中涉及的任何數據庫版本都不正確,則發布過程將失敗,因為無法進行一項或多項要求的檢查,或者更糟的是,對于錯誤的版本進行了檢查。
在開發中,您需要掌握數據才能快速工作,而部署中則是另一回事。您可以構建一個dev數據庫并復制所需的任何數據,但是測試數據庫或UAT數據庫將需要精心策劃的數據。要更新或回滾這樣的數據庫,您需要一個遷移腳本。每個新發行版都需要一個遷移腳本,該腳本會將先前發行的版本更改為新發行版。因為它僅對目標數據庫的特定版本有效,所以它需要檢查目標的版本并僅在目標版本正確時運行。這是發行版所需的唯一遷移腳本,盡管俗世也將添加反方向運行的回滾腳本。
使用SQL Compare的遷移腳本作為起點
創建一個有效的腳本來在版本之間遷移數據庫應該是一個簡單的過程,但是不要指望它。候選發布版本將與生產版本有所不同。如果您已經重新設計了表結構,或者重命名了許多例程,列或表,那么您的模式比較工具可能無法始終如您所愿地工作。它將需要幫助來保存現有數據。如果不能,它可能會通知您,但可能不會。
那你該怎么辦 第一個本能是手工剪切遷移腳本。我退縮了,只是在想,因為細節很重要,惡魔潛伏在那里。忘記所有與大型變更同時進行的細微變更非常容易,您要么過分樂觀,部署失敗,要么被困在幾乎無法修改的修改-測試-修改-測試周期中確保遷移腳本有效。我的首選是建立并修改自動生成的遷移腳本,該腳本是模式比較的輸出,由SQL Compare完成。這是因為SQL Compare(通過檢查它生成的腳本會注意到)能夠進行許多巧妙的遷移,而簡單的手工剪切ALTER腳本會失敗。
盡管遷移腳本是您在部署管道中使用的腳本,但重要的是不要在開發過程中因遷移問題而過于分散注意力。數據庫開發人員應該能夠進行很多逐步改進,甚至沉迷于實驗,而不必擔心下游麻煩。您可以將所有次要內容委托給構建過程。即使當您從根本上更改表時,SQL Compare有時有時無法介意您的意圖,它仍然會占用所有較小的內容。您需要做的就是添加棘手的遷移代碼,該代碼很可能已經被開發人員剪切和測試,作為特定的遷移腳本。畢竟,開發人員無論如何都必須這樣做以修改其測試數據,以準備在開發過程中測試每個新版本的構建。
您需要了解的一些SQL比較約定
SQL Compare自動生成一個遷移腳本,該腳本將使目標數據庫的架構與源數據庫的架構匹配。它旨在確保此腳本成功完成或回滾,不留下任何痕跡。為此,它會在每個DDL語句(例如或)之后檢查錯誤級別CREATE,并且如果發生了不會導致腳本立即回滾或終止的錯誤,它將設置連接狀態,直到該操作不再執行。最終使用。例如:ALTERGRANTIF @@ERROR <> 0 SET NOEXEC ON
RINT N'Altering [dbo].[byroyalty]' GO ALTER PROCEDURE [dbo].[byroyalty] @percentage int AS select au_id from titleauthor where titleauthor.royaltyper = @percentage GO IF @@ERROR <> 0 SET NOEXEC ON GO
腳本末尾有非常重要的批處理,可以捕獲任何錯誤。
DECLARE @Success AS BIT SET @Success = 1 SET NOEXEC OFF IF (@Success = 1) PRINT 'The database update succeeded' ELSE BEGIN IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION PRINT 'The database update failed' END
如果此時SQL Server仍在執行代碼,它將聲明一個名為的變量@success并將其設置為true。然后,它將設置連接以執行代碼,而不管是否存在錯誤。如果將變量成功設置為true,則遷移腳本被視為成功。否則,任何事務都會回滾,并且更新失敗。
要成為一個體貼的參與者,在適應此腳本時,您將需要在每個DDL SQL語句之后檢查錯誤變量,并設置NOEXEC ON是否存在會影響遷移的錯誤。切勿NOEXEC OFF在更改SQL比較腳本時在使用的代碼中進行設置!
在數據庫上標記版本
“版本化”數據庫的唯一確定方法是通過擴展屬性在數據庫上標記版本。尚無確定的標準。在準備第一個定制SQL Compare腳本的示例時,讓我們獲得一種就地對數據庫進行版本控制的簡單方法。稍后,這將使我們能夠適當地使用遷移腳本,而無需進行詳盡的檢查。
這是一些代碼,可讓您在數據庫(在本例中為Pubs數據庫)中設置版本號。
SET NOEXEC off go USE pubs DECLARE @DatabaseInfo NVARCHAR(3750), @version NVARCHAR(20) SET @version=N'2.1.5' SELECT @DatabaseInfo = ( SELECT 'Pubs' AS "Name", @version AS "Version", 'The Pubs (publishing) Database supports a fictitious bookshop.' AS "Description", GetDate() AS "Modified", SUser_Name() AS "by" FOR JSON PATH ); IF not EXISTS (SELECT name, value FROM fn_listextendedproperty( N'Database_Info',default, default, default, default, default, default) ) EXEC sys.sp_addextendedproperty @name=N'Database_Info', @value=@DatabaseInfo ELSE EXEC sys.sp_Updateextendedproperty @name=N'Database_Info', @value=@DatabaseInfo
創建Database_Info擴展屬性后,我們現在可以使用版本標記原始數據庫。在開發數據庫的新版本時,我們可以很簡單地將相同版本的圖章和更新的版本號放在同一位置。如果在事務中完成,它將在成功遷移后自動復制到目標。
在GitHub中,在提交源代碼之前,我們可以在version.json文件中維護數據庫的版本號,并將其設置為正確的版本號。該版本號將不在對象級源中,因為它是數據庫本身的屬性。但是,如果您使用實時數據庫作為源,它將在遷移腳本中。上面的代碼在Github中為AddInitialVersion.sql。
建立實踐實驗室
為了進行簡單的演示,我們將從好奇的柜子中取出古老的pubs數據庫,并將其安裝為“假裝”生產服務器。我們將創建一個Github項目,其目的是使數據庫更新一些。
我們會假裝我們的Pubs數據庫的“生產”副本(當前版本)的版本為2.1.5,因此將其標記為該版本。這是一個只讀參考數據庫,可用作測試數據的源,并用于在開發過程中運行測試時檢查數據是否未更改。pubs的備份在這里。
要在其上標記版本,可以使用此方法,它假定Database_Info擴展屬性尚不存在。
EXEC sp_addextendedproperty N'Database_Info', N'[{"Name":"Pubs","Version":"2.1.5","Description":"The Pubs (publishing) Database supports a fictitious bookshop.","Modified":"2020-05-06T13:57:56.217","by":"PhilFactor"}]', NULL, NULL, NULL, NULL, NULL, NULL;
為了模擬開發過程,我們將在開發服務器上安裝原始Pubs數據庫的另一個副本,并在生產中使用當前 版本。這表示起始版本,即您要更改以創建新版本的版本。通過引用當前版本(以及當前發行版),您可以隨時了解遷移腳本需要實現的目標。對于某些團隊來說,這可能是一個共享的開發數據庫。
相關產品推薦:
SQL Prompt:SQL語法提示工具
SQL Toolbelt:Red Gate產品套包
SQL Monitor:SQL Server監控工具
本站文章除注明轉載外,均為本站原創或翻譯。歡迎任何形式的轉載,但請務必注明出處、不得修改原文相關鏈接,如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn
文章轉載自: