SQL Compare怎樣使用SQL比較命令行從源代碼管理中進行自定義部署

這期內容當中小編將會給大家帶來有關SQL Compare怎樣使用SQL比較命令行從源代碼管理中進行自定義部署，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

SQL Compare是一款比較和同步SQL Server數據庫結構的工具。現有超過150,000的數據庫管理員、開發人員和測試人員在使用它。當測試本地數據庫，暫存或激活遠程服務器的數據庫時，SQL Compare將分配數據庫的過程自動化。

Giorgi Abashidze解釋了他的團隊如何使用帶有SQL Compare命令行和一些SQL同義詞的兩階段部署過程來自動為其每個客戶進行自定義部署，而只需要在源代碼管理中為每個版本維護一個分支。

在我以前的文章中，從使用SQL比較命令行的源代碼控制到數據庫，我解釋了我的團隊如何使用SQL比較命令行為我們的客戶自動化數據庫部署，而無需訪問實際的暫存數據庫或生產數據庫，這是不可能的這是一個銀行數據庫。我展示了如何通過僅訪問我們的開發數據庫（包含在TFS源代碼管理下），如何使用SQL Compare命令行來部署數據庫元數據和所有客戶通用的代碼。

但是，除了此共享代碼外，還必須為我們的每個客戶提供每個軟件版本的獨特變體，以便向他們提供可滿足其不同業務和合規性要求的自定義例程。我們每個客戶都需要其中一些例程，當然，此專有功能應始終僅部署到該客戶的生產數據庫中：至關重要的是，任何客戶都不能看到專門為另一位客戶編寫的邏輯。

我們如何實現這一目標？傳統的觀點似乎是，在每個發行版中，我們將數據庫版本的每個特定于客戶的變體視為一個單獨的分支。但是，這可能會增加構建的復雜性。有了一些創造力，我們可以避免這種情況，而是為每個新版本創建一個分支，我們可以使用該分支來維護和部署我們每個客戶的所有共享邏輯，以及專用于無限數量客戶的邏輯。

在本文中，我將說明如何使用SQL Compare命令行，同義詞和一些獨創性來完成所有這些工作。

我們如何將客戶特定的例程存儲在單個數據庫中

因此，為了更接近我們的開發數據庫的構建方式，我們假設我們的Trunk結合了我們所有的邏輯。假設我們有三個客戶Cust1，Cust2和Cust3。

我們還有一些代碼，即SQL存儲過程，稱為SQL存儲過程loan.calculate_effective_rate，該過程根據某種算法來計算在一段時間內對貸款支付的實際利率，稱為“有效利率”。對于所有客戶來說，這是相同的代碼，但是有一天，客戶Cust1要求我們更改其版本的算法，這意味著我們現在需要維護和部署“有效率”過程的兩個不同版本。

首先，我們需要effective_rate按照Cust1的要求，為該過程實現替代算法（從這里開始，我將使用其名稱的這種縮寫形式）。我們只有一個開發數據庫，稱為Trunk，并且由于任何例程中每個例程的名稱都必須唯一，這意味著我們必須有一種命名策略來區分這些變體。

我們這樣做的方法是：

1. 將effective_rate過程重命名為effective_rate_default，為我們的客戶創建默認的計算實現。

2. 創建一個名為的新過程effective_rate_cust1。就參數和參數類型而言，它應具有與舊簽名相同的簽名。這必須僅部署到Cust1組織。

這意味著所有客戶的應用程序代碼現在都必須調用該effective_rate_default過程，但必須調用的Cust1除外effective_rate_cust1。但是，我們不希望對任何客戶的調用代碼進行任何更改。畢竟，該程序的目的沒有改變，但是我們現在有多個實施同一操作（計算貸款的有效利率）的方法。相反，我們使用同義詞表示具有多個實現的任何動作。換句話說，調用者代碼從不直接調用確切的實現，而是調用操作（SQL同義詞）。

因此，在這種情況下，我們將創建一個SQL同義詞并將其部署到每個客戶，該SQL同義詞具有effective_rate引用該effective_rate_default過程的名稱。當然，Cust1僅此同義詞必須不引用默認過程，而是引用Cust1變體。但是，正如我已經提到的，我們在源代碼管理中僅維護一個數據庫，而在Trunk（以及任何發行分支）中，每個同義詞始終僅引用相關操作的默認實現。那么我們如何實現這一目標呢？

答案是一個兩階段的部署過程。第一階段向每個客戶部署effective_rate_default過程以及effective_rate引用該過程的同義詞。第二階段僅將過程部署到Cust1 ，然后在Cust1數據庫中刪除同義詞，并創建一個引用的新過程。

effective_rate_cust1effective_rateeffective_rate_cust1

通過遵循這種方法，基于對每個客戶的SQL同義詞和兩階段部署過程，我們可以在一個開發數據庫中包含所需的專用例程，因此仍然可以為我們的客戶提供代碼，考慮到不同的業務和合規性要求。

讓我們看看如何使用SQL Compare命令行實現此兩階段部署過程。

使用SQL比較的2階段部署

我們將在簡化的部署示例中稍作擴展，并假設有三個客戶（Cust1，Cust2和Cust3）都需要定制“有效率”算法的變體。

部署過程的第一階段將生成一個部署腳本，該腳本將交付給每個客戶數據庫并在每個客戶數據庫上運行。這將使所有通用數據庫例程（即，沒有名稱以客戶別名結尾的任何例程）升級到相同版本。

第二階段生成零個或多個特定于客戶的同步腳本，這些腳本僅創建或更新特定于該客戶的SQL例程，這意味著任何例程的名稱都以該用戶的別名結尾，在這種情況下，cust1，cust2或cust3。它還將刪除并重新創建任何同義詞，在本例中為effective_rate同義詞，以便每個人始終綁定到正確的基礎實現。

為了滿足這些要求，我們對所需的每個同步腳本執行一次SQL比較命令行。

階段1：生成常規部署腳本

在部署過程的第一階段，我們只執行一次SQL Compare CL，并通過提供一個名為“ shared.xml ” 的XML argfile，傳入指示其比較哪些數據庫以及如何進行比較的所有參數：

“％programfiles（x86）％\ Red Gate \ SQL Compare 13 \ sqlcompare” /Argfile:"shared.xml“

我在上一篇文章中解釋了此Argfile的基本內容，但重要的一點是，首先，它是直接從源代碼控制位置比較數據庫的兩個即時點版本，即新版本和先前版本。 ，其次包括對相應過濾器文件（shared.scpf）的引用。此過濾器文件使用如下所示的過濾器表達式排除任何特定于客戶的模式對象版本（在這種情況下，任何以Cust1，Cust2或Cust3結尾的版本）：

(@NAME NOT LIKE '%[_]cust1') AND (@NAME NOT LIKE '%[_]cust2') AND (@NAME NOT LIKE '%[_]cust3')

當然，如果您的客戶別名全部遵循標準模式（如本簡化示例中的做法），則可以使用更通用的過濾器，例如(@NAME NOT LIKE' %[_]cust[0-9]')。但是，我們所有的真實客戶名稱都不相同，因此不可能進行這種模式匹配。

結果，SQL Compare將生成一個SQL同步腳本，該腳本將僅創建effective_rate_default存儲過程，然后刪除該effective_rate同義詞，然后重新創建該同義詞，以使其引用默認過程（CREATE SYNONYM effective_rate FOR effective_rate_default）。

階段2：生成客戶特定的部署腳本

實際上，對于每個客戶，此階段包括兩個部分：

1. SQL Compare自動生成一個腳本，該腳本將創建或修改所需的特定于客戶的例程

2. 我們“重置”每個客戶數據庫中的所有同義詞，以便它們引用正確的基礎實現（存儲過程或函數等）。為此，我們將所需的代碼“注入”到每個自動生成的自定義腳本的末尾

我們針對需要自定義代碼的每個客戶再次執行SQL Compare CL，只需簡單地每次切換argfile即可指示SQL Compare 僅包含名稱以該客戶的別名結尾的對象。我們將所有客戶別名的列表存儲在開發數據庫中。

“％programfiles（x86）％\ Red Gate \ SQL比較13 \ sqlcompare” /Argfile:"cust1.xml“
“％programfiles（x86）％\ Red Gate \ SQL比較13 \ sqlcompare” /Argfile:"cust2.xml“
“％programfiles（x86）％\ Red Gate \ SQL比較13 \ sqlcompare” /Argfile:"cust3.xml“

每個argfile的內容與shared.xml文件的內容幾乎相同，唯一的區別是每個特定于客戶的argfile包含對該客戶的過濾器文件的引用（例如Cust1.scpf），該引用指示SQL Compare CL使用以下表達式，僅檢測特定于該客戶的更改

(@NAME LIKE '%[_]cust1')

當比較運行時（例如對于Cust1），SQL Compare將生成一個部署腳本，該腳本將創建，修改或刪除*_cust1代表Cust1已安裝版本的主干分支中的任何對象，因此它將與源代碼控制中的最新版本同步。在這種情況下，它將創建effective_rate_cust1存儲過程。

但是，SQL Compare為每個客戶自動生成的部署腳本不會將當前的effective_rate同義詞（通過在階段1中運行通用腳本創建）替換為引用effective_rate_cust1存儲過程的同義詞，因為該同義詞在Trunk或任何單個分支中對于每個主要版本（v241，v242等），始終引用默認實現。

因此，每次SQL Compare自動生成特定于客戶的同步腳本時，我們都需要對其進行修改，以“重置”腳本中的任何同義詞，以便它引用相關操作的特定于特定于客戶的實現，或者如果不再需要自定義變體，則恢復為默認操作。

我們不能為此使用標準的SQL Compare部署后腳本，首先，因為當直接與源代碼控制位置進行比較時，該工具當前不支持使用它們。無論如何，由于我們簡單的“每個發布一個分支”策略，我們無法動態地為每個客戶生成部署后腳本，也無法更改每個腳本中的同義詞以引用正確的客戶實現。使其起作用的唯一方法是使用“每個版本的每個客戶變體一個分支”的更復雜的構建方案，將每個分支腳本化到一個文件夾中，然后向其中添加一個后部署腳本，以為此重置同義詞。

但是，我們更喜歡使用更簡單的源代碼控制方法，那么我們該怎么做呢？當SQL Compare將特定于客戶的同步文件寫入我們選擇的目錄（由該out客戶的XML argfile中的參數指定）時，我們將使用一個本地工具將其打開，并在自動生成的代碼的末尾添加一行，以執行我們編寫的存儲過程稱為switch_synonyms_to_customer。此過程接受組織的別名的參數（應將同義詞綁定到該參數），然后遍歷所有SQL同義詞，將它們逐個刪除，然后使用同義詞引用的基礎對象的適當名稱重新創建它們。默認值或專用例程（如果特定客戶需要）。

因此，對于cust1：

EXEC altasoft.switch_synonyms_to_customer @alias = 'cust1'

對于cust2：

EXEC altasoft.switch_synonyms_to_customer @alias = 'cust2'

等等…

為每個客戶運行部署

我們向每個客戶提供用于部署所有公共對象的常規部署腳本，并且，如果需要，我們還為每個客戶提供為其定制邏輯提供的其他自定義部署腳本，該腳本還將正確重置所有同義詞。他們必須始終始終先運行常規腳本，只有完成后才運行其自定義腳本。

如果您正在為許多不同的客戶開發數據庫應用程序，那么您的客戶的需求將開始出現分歧，并且單個部署無法滿足您的需求。畢竟，當地的稅收和法律以及不同的商業慣例將決定客戶如何計算某些財務價值。

為了將所需邏輯中的所有變體僅提供給需要它的客戶，SQL Compare命令行可以完成99％的工作。它會生成一個通用同步腳本，以部署每個客戶所需的從發行到發行的任何更改，然后針對具有“特殊”要求的每個客戶生成單獨的同步腳本文件。

通過使用同義詞表示每個必需的業務操作，并在每個特定于客戶的同步腳本的末尾“手動”重置它們，以便它們始終引用此操作的正確實現，我們避免了對調用者進行任何更改碼。

在每個發行版中，都有可能為客戶創建了一些新邏輯，或者更新了現有的自定義邏輯或將其刪除。如果某些操作不再需要自定義實現，則將其刪除，因此客戶將返回該操作的默認實現。

上述就是小編為大家分享的SQL Compare怎樣使用SQL比較命令行從源代碼管理中進行自定義部署了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。