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

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

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

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

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

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

我們?nèi)绾螌崿F(xiàn)這一目標？傳統(tǒng)的觀點似乎是，在每個發(fā)行版中，我們將數(shù)據(jù)庫版本的每個特定于客戶的變體視為一個單獨的分支。但是，這可能會增加構建的復雜性。有了一些創(chuàng)造力，我們可以避免這種情況，而是為每個新版本創(chuàng)建一個分支，我們可以使用該分支來維護和部署我們每個客戶的所有共享邏輯，以及專用于無限數(shù)量客戶的邏輯。

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

我們?nèi)绾螌⒖蛻籼囟ǖ睦檀鎯υ趩蝹€數(shù)據(jù)庫中

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

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

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

我們這樣做的方法是：

1. 將effective_rate過程重命名為effective_rate_default，為我們的客戶創(chuàng)建默認的計算實現(xiàn)。

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

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

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

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

effective_rate_cust1effective_rateeffective_rate_cust1

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

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

使用SQL比較的2階段部署

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

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

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

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

階段1：生成常規(guī)部署腳本

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

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

我在上一篇文章中解釋了此Argfile的基本內(nèi)容，但重要的一點是，首先，它是直接從源代碼控制位置比較數(shù)據(jù)庫的兩個即時點版本，即新版本和先前版本。 ，其次包括對相應過濾器文件（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同步腳本，該腳本將僅創(chuàng)建effective_rate_default存儲過程，然后刪除該effective_rate同義詞，然后重新創(chuàng)建該同義詞，以使其引用默認過程（CREATE SYNONYM effective_rate FOR effective_rate_default）。

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

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

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

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

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

“％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的內(nèi)容與shared.xml文件的內(nèi)容幾乎相同，唯一的區(qū)別是每個特定于客戶的argfile包含對該客戶的過濾器文件的引用（例如Cust1.scpf），該引用指示SQL Compare CL使用以下表達式，僅檢測特定于該客戶的更改

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

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

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

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

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

但是，我們更喜歡使用更簡單的源代碼控制方法，那么我們該怎么做呢？當SQL Compare將特定于客戶的同步文件寫入我們選擇的目錄（由該out客戶的XML argfile中的參數(shù)指定）時，我們將使用一個本地工具將其打開，并在自動生成的代碼的末尾添加一行，以執(zhí)行我們編寫的存儲過程稱為switch_synonyms_to_customer。此過程接受組織的別名的參數(shù)（應將同義詞綁定到該參數(shù)），然后遍歷所有SQL同義詞，將它們逐個刪除，然后使用同義詞引用的基礎對象的適當名稱重新創(chuàng)建它們。默認值或?qū)Ｓ美蹋ㄈ绻囟蛻粜枰?/p>

因此，對于cust1：

EXEC altasoft.switch_synonyms_to_customer @alias = 'cust1'

對于cust2：

EXEC altasoft.switch_synonyms_to_customer @alias = 'cust2'

等等…

為每個客戶運行部署

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

如果您正在為許多不同的客戶開發(fā)數(shù)據(jù)庫應用程序，那么您的客戶的需求將開始出現(xiàn)分歧，并且單個部署無法滿足您的需求。畢竟，當?shù)氐亩愂蘸头梢约安煌纳虡I(yè)慣例將決定客戶如何計算某些財務價值。

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

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

在每個發(fā)行版中，都有可能為客戶創(chuàng)建了一些新邏輯，或者更新了現(xiàn)有的自定義邏輯或?qū)⑵鋭h除。如果某些操作不再需要自定義實現(xiàn)，則將其刪除，因此客戶將返回該操作的默認實現(xiàn)。

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