SQL Compareは、SQLServerデータベースの構造を比較および同期するためのツールです。150,000人を超えるデータベース管理者、開発者、およびテスターがこれを使用しています。ローカルデータベースをテストするとき、リモートサーバー上のデータベースをステージングまたはアクティブ化するとき、SQLCompareはデータベースを割り当てるプロセスを自動化します。
SQLCompareの試用版をダウンロードするにはクリックしてください[Huidu.com]
私たちのチームは、主にジョージアン銀行などの商業組織向けの実用的なアプリケーションを開発しています。これらのアプリケーションは、データベースとしてMS SQLServerを使用する.Net-Windows-Formsアプリケーションに基づいています。これらには、ストアドプロシージャ、関数、ビュー、SQLCLRなどのデータベースルーチンに含まれる多くのビジネスロジックがあります。
当然のことながら、お客様のビジネスの性質上、開発、テスト、または展開のためにお客様のデータベースまたはデータにアクセスする権利はありません。TFSソースコード管理では、開発データベースとその手動テストデータのみがあります。開発者はデータベースの独自のコピーで作業し、各コピーには独自のサンプルデータがあり、Redgate SQL SourceControlを使用して開発の変更を送信します。次に、SQL比較コマンドラインを使用して、データベースの展開を自動化します。この記事では、この目標を達成する方法を説明し、同じブランチまたは異なるブランチにあるデータベースの2つのリビジョンを比較し、展開スクリプトを生成する方法の例を示します。
コマンドライン権限
SQL比較コマンドラインを複数のコンピューターにインストールする必要がある自動化プログラムには、RedgateDeployまたはSQLToolbeltライセンスが必要です。詳細については、ドキュメントの「コマンドライン配布の変更」ページを参照してください。
ソース管理でデータベースを管理する
私たちのデータベースのソースコード管理と分岐戦略は単純です。Trunkには最新のコードベースがあります。データベース部分を含むアプリケーション全体がそこにあります。すべての新機能とバグ修正は、最初はトランクで実行されます。作成する各ブランチはトランクの単なるコピーであるため、コードベースの完全なポイントインタイム状態を表します。いくつかの変更を適用してトランクをチェックインした後、必要に応じてそれらをこれらのブランチのいずれかにマージできます。通常、これは報告されたバグを修正するためのものですが、お客様にとって重要な場合は、機能の小さな変更を組み込むこともできる必要があります。たとえば、すべての顧客が各バージョンを展開できるわけではないため、展開するバージョンは通常3〜4遅れています。ただし、現在のバージョンの緊急修正を展開する必要があり、場合によってはいくつかの「排他的」機能を使用する必要があります。
では、ソフトウェアを開発するとき、これらすべてはどのように機能するのでしょうか。これを「under-source-control-application」（略してUSCAPP）と呼びましょう。USCAPP_Trunkに最新のコードベースがあり、TFSブランチの下にv241、v242などと呼ばれるいくつかのリリースバージョンがあります。
直接またはマージによって行われたすべての変更は、トランクとそのブランチの通常のTFSチェックインを介して行うことができます。TFSは、チェックインのたびに、一意の参照番号を持つチェンジセットと呼ばれるものを作成します。変更セットは、ソース管理のコードベース全体のスナップショットを表します。他のソースコード管理システムと同様に、TFSは、任意のリビジョン（任意の変更セット番号に対応）のコードベースのポイントインタイム状態を生成できます。
もちろん、コレクション内のすべてのTFSプロジェクト（そのブランチを含む）の場合、TFS変更セット番号はグローバルであり、プロジェクトコレクションがチェックインされるたびにその番号が増加します。私たちにとって、これは、USCAPP_Trunkとそのすべてのブランチv241、v242などがすべて同じグローバルで増加する変更セット番号を共有することを意味します。
開発者は変更を加え、全員が専用のデータベースで作業し、SQLソース管理を介して変更をチェックインします。SQLソース管理により、USCAPP_Trunkのコードが更新されます。必要に応じて、必要な変更セットを他のブランチにマージし、これらのブランチに新しい変更セットを作成します。したがって、最新バージョンがv245であり、お客様Aがv242を実稼働環境にデプロイしたことがわかっているとします。お客様はまだ最新バージョンにアップグレードしていませんが、他のアップグレードスクリプトを展開して、いくつかのバグを修正し、いくつかの小さな改善を行っています。つまり、顧客Aは非常に特殊なバージョンのv242を実行しており、それをTFS変更セット番号に変換できます。これにより、展開したブランチv242のコードベースの特定の時点の状態が一意に識別されます。
SQL Compareコマンドラインを使用して、変更スクリプトを自動的に生成します
私たちの目標は、スクリプトが最後に公開されてから発生したすべての変更をカバーする同期SQLスクリプトを生成するプロセスを自動化することです。
顧客Aがブランチv242をデプロイし、データベースのリリースバージョンが人間が読めるバージョン番号2.4.2.0でマークされていると仮定します。これは、変更セット番号87300に対応します。つまり、変更セット87300が現在の最新バージョンコードベースのグローバル変更セット番号。
1か月後、データベースに変更を加えました。現在、TFSの変更セットの現在の数は88100です。ここで、今月に行われたすべての変更を含むスクリプトを生成するため、データベースのv2.4.2.0を、v2.4.2.1と呼ばれる変更セット番号88100で表される状態にアップグレードします。
これを行うには、TFSから2つの時点でのデータベースの状態を取得する必要があります。1つはソースデータベースを表し（変更されません）、もう1つはターゲットデータベースを表します（アップグレードします）。したがって、顧客Aの場合、変更セット88100はソースを表し、87300はターゲットを表します。2つの状態を比較して違いを見つけてから、状態がソースと同じになるようにターゲットを同期するスクリプトを生成する必要があります。両方のデータベースに存在するが異なるデータベースオブジェクトの場合、ターゲットのオブジェクトの定義を変更して、ソースの定義と一致させる必要があります。ソースには存在するがターゲットには存在しないオブジェクトを作成し、ターゲットには存在するがソースには存在しないオブジェクトを削除する必要があります。
幸いなことに、これを手動で行う必要はありません。SQL CompareGUIとSQLCompareコマンドラインの両方がこの機能をサポートしています。プロセスを自動化したいので、コマンドラインを使用し、適切なパラメーターをコマンドラインに渡して同期スクリプトを生成します。また、データベースの2.4.2.0バージョンをv2.4.2.1にアップグレードするには、スクリプトを注意深く記録する必要があります。もちろん、ここでもいくつかの保護対策が必要です。それらの1つはチェックであり、v2.4.2.0以降のデータベースでこのスクリプトの実行を停止します。ここでは説明しませんが、最後に、これらの要件について詳しく説明します。
同じブランチ内の2つのリビジョンを比較します
最初に、「修正」と呼ばれるスクリプトをリリースする方法について説明します。このスクリプトは、主にいくつかのバグ修正とマイナーな改善を展開するために使用されます。メジャーバージョンは変更されていません。
これを行うには、SQL Compareコマンドラインを使用して、SQL Compareに比較の実行方法を指示するすべての必要なコマンドラインスイッチの値を含むXMLパラメーターファイル（argfile）を渡します。または、コマンドラインへのすべてのスイッチ、またはPowerShellの「splat」パラメーターを指定することもできます。
この場合、SQL Compareに渡す必要がある唯一のパラメーターは、「shared.xml」と呼ばれるXMLArgfileの修飾ファイル名です。
"％Programfiles（x86）％\ Red Gate \ SQL Compare 13 \ sqlcompare" /Argfile:"shared.xml "argfile
の内容は、SQLCompareコマンドラインのオンラインドキュメントに記載されているとおりに正確に入力する必要があります。これは実際の例です：
<commandline>
<SourceControl1 />
<Revision1> 88100 </ Revision1>
<SourceControl2 />
<Revision2> 87300 </ Revision2>
<Options> NoDeploymentLogging、IgnoretSQLt、IgnoreFillFactor、IgnoreWhiteSpace、IgnoreFileGroups、IgnoreUserGroups、IgnoreFileGroups IgnoreUserProperties、IgnoreDatabaseAndServerName、CaseSensitiveObjectDefinition、ObjectExistenceChecks、DropAndCreateInsteadofAlter、ForceColumnOrder、DoNotOutputCommentHeader、IgnoreUsersPermissionsAndRoleMemberships </オプション>
<ScriptsFolderXML>コマンドライン\ SourceControlAddress v242.xml </ ScriptsFolderXML>
<フィルター>
<ReportType> Interactive </ ReportType>
<Report> Command Line \ Output \ Shared.html </ Report>
<ScriptFile> Command Line \ Output \ Shared.sql </ ScriptFile>
<Force />
<Verbose />
</ commandline>
Argfileには5つのコマンドラインスイッチが含まれており、これらを使用して目的の動作を定義します。/ Sourcecontrol1スイッチと/ Sourcecontrol2スイッチは、ソースとターゲットがソース管理スクリプトのフォルダーであることを指定します。この場合、それぞれ88100と87300を変更します。
<SourceControl1 />
<Revision1> 88100 </ Revision1>
<SourceControl2 />
<Revision2> 87300 </ Revision2>
<ScriptsFolderXML>スイッチには、完全なファイルパスがXMLファイルSourceControlAddressv242.xmlとして含まれています。このファイル（以下に表示）には、ブランチv242データベースのソースコード管理アドレスが含まれています。
<？xml version = "1.0" encoding = "utf-16" standalone = "yes"？>
<ISOCCompareLocation version = "
;
<SourceControlFolder> $ / USCAPP / Branches / v242 / Database / Schema </ SourceControlFolder>
</ ISOCCompareLocation>
これは、SQLCompareが87300および88100変更セットを復元する必要があるアドレスです。コマンドラインバージョンのSQLCompareを実行すると、これらの変更セットが「スクリプトフォルダー」（執筆時点ではWindows Tempのフォルダー）に復元され、比較のソースとして88100、ターゲットとして87300が使用されます。最終的なアップグレードスクリプトを生成します。
2つの異なるブランチのデータベースを比較します
Trunkで完了したすべての新機能をリリースするために使用するプロセスは、バグ修正バージョンとは少し異なりますが、主要な概念は同じです。この場合も、データベースアーキテクチャの2つの異なる状態を比較する必要があります。それらの「信頼できる情報源」がTFSソース管理のバージョンとして存在する場合でも、Redgateが「スクリプトフォルダー」と呼ぶフォルダーにエクスポートされます。次に、それらを2つのデータベーススキーマとして比較できます。この場合の違いは、1つのTFSブランチで設定された変更によって表される2つのリビジョン（または特定の時点の状態）を比較する代わりに、現在バージョンを表す2つのブランチを比較することです。
ステップバイステップで進めるには：プロセスは最初にトランクブランチから新しいブランチを作成し、それに適切な名前を割り当てます。たとえば、v2.4.2がUSCAPPアプリケーションの最後にリリースされたバージョンである場合、このバージョンがリリースされたときに、v242という名前のブランチを作成しました。トランクにさらに変更を加えたので、論理的にはバージョンv2.4.3をリリースするので、新しいブランチはv243と呼ばれ、それ以降、含まれる内容に関しては、トランクの正確なコピーとして機能します。ブランチ。
ここで、2つの別々のブランチの2つの変更セットを比較する必要があります。比較に使用する変更セットは、作成されたばかりの新しいv243ブランチの変更セットと、顧客Aが適用した前のブランチv242の最新の展開スクリプトに対応する変更セットである必要があります。この比較により、以前のブランチv242のデータベースから欠落していた、トランクのデータベースでのみ発生した変更が明らかになります。
このために、2つのソース管理フォルダーの場所ではなく1つを指定する必要があります。1つはsource / ScriptsFolderXML1を含むTFSブランチ用で、もう1つはtarget / ScriptsFolderXML2を含むブランチ用です。SQL Compareの予約済みキーワード「HEAD」を使用して、ソースブランチの最新のソース管理変更セットが必要であることを指定します。生成されるArgfileは次のとおりです。
<commandline>
<SourceControl1 />
<Revision1> HEAD </ Revision1>
<SourceControl2 />
<Revision2> 88100 </ Revision2>
<Options> NoDeploymentLogging、IgnoretSQLt、IgnoreFillFactor、IgnoreWhiteSpace、IgnoreFileGroups、IgnoreUserProperties、Igno 、IgnoreDatabaseAndServerName、CaseSensitiveObjectDefinition、ObjectExistenceChecks、DropAndCreateInsteadofAlter、ForceColumnOrder、DoNotOutputCommentHeader、IgnoreUsersPermissionsAndRoleMemberships </ Options>
<ScriptsFolderXML1>コマンドライン\ SourceControlAddressv243.xml </ ScriptsFolderXML1>
<ScriptsFolderXML2> Command Line \ SourceControlAddress v242.xml </ ScriptsFolderXML2>
<Filter> Command Line \ Filters \ Shared.scpf </ Filter>
<ReportType> Interactive </ ReportType>
<Report> Command Line \ Output \ Shared.html </レポート>
<ScriptFile> Command Line \ Output \ Shared.sql </ ScriptFile>
<Force />
<Verbose />
</ commandline>
管理脚本本XML文件（SourceControlAddress v242.xml）：
<？xml version = "1.0" encoding = "utf-16"
Standal = "yes"？> <ISOCCompareLocation version = "1" type = "TfsLocation">
<ServerUrl> http：// tfs：8080 / tfs / projects </ ServerUrl> ;
<SourceControlFolder>
これはソースコードの1つです（SourceControlAddress v243.xml）：
<？xml version = "1.0" encoding = "utf-16"
特にstandalone = "yes"？> <ISOCCompareLocation version = "1" type = "TfsLocation">
< ServerUrl> http：// tfs：8080 / tfs / projects </ ServerUrl> ;
<SourceControlFolder> $ / USCAPP / Branches / v243 / Database / Schemea </ SourceControlFolder>
</ ISOCCompareLocation>
ここでも、Argfileのアドレスのみを使用します。 SQL Compareコマンドラインを呼び出す唯一のパラメータとして：
"％programfiles（x86）％\ Red Gate \ SQL Compare 13 \ sqlcompare" /Argfile:"shared.xml "
SQL Compareコマンドラインでの作業が完了したら、ファイル "Shared.sql"、ターゲットデータベースで実行して最新のメジャーバージョンにアップグレードできるアップグレードスクリプトがあります。
さらなるリクエスト
実際には、自動生成されたスクリプトを常に注意深くチェックし、チェックとコントロールを追加して、たとえば、必要なすべてのアップグレードスクリプトを予想されるデータベースバージョンに正しい順序で適用したことを確認する必要があります。また、データ挿入の処理や各スクリプトへのヘッダー情報の追加（スクリプトの作成時、著作権情報、連絡先情報など）など、SQLCompareの自動生成された展開スクリプトを少量追加してカスタマイズする必要があります。）、または動的に生成されたSQLスクリプトを、自動生成された各スクリプトの最後に追加して、顧客を識別します。
カスタム移行スクリプトを使用してSQLCompareの展開を調整することで、これらの目標の多くを達成できますが、実際には、SQLソース管理や展開前および展開後のスクリプトの実行速度が低下するなどの問題が発生しています。
カスタム状態ベースの展開
Phil Factorには、展開前および展開後のスクリプトを使用して、状態ベースの展開に適応し、トリッキーなデータ移行を処理したり、ターゲットデータベースにバージョン番号を追加したり、データベース設定を指定したりする方法を示す優れた記事がいくつかあります。
考慮する必要のあるもう1つの問題は、SQL Compareの移行と展開前または展開後のスクリプトは静的であり、要件は動的に生成されたスクリプトであるということです。代わりに、開発者がSQLCompareスクリプトに小さな動的な追加やカスタマイズを行えるようにするシンプルで軽量なツールをVisualStudioで構築しました。
ここで詳しく説明しないもう1つの問題は、ソースコード管理バックボーンが、顧客データベースのすべての共有ロジックと、その組織に固有のカスタムコードを含む小さなルーチンを組み合わせていることです。この記事では、SQL Compareコマンドラインを使用して、すべての顧客に共通のデータベース構造とコードを展開する方法を示しました。プロセスは基本的に顧客固有のルーチンと同じですが、固有の機能が常にその顧客の本番データベースにのみ展開され、他の顧客専用であることを顧客が確認できないようにするには、若干の調整が必要です。ロジック執筆の。この目標をどのように達成するかについては、次の記事で説明します。
結論として
私たちの経験では、Redgate SourceControlとSQLCompareは連携して機能し、自動化されたスクリプト生成プロセスで大きな役割を果たすことができます。SQL Compareを使用すると、GitまたはTFSソースコード管理からスクリプトを抽出する方法を非常に細かく制御できるため、手動でのスクリプト作成を大幅に節約できます。対応するロールバック（ダウングレード）スクリプトとアップグレードスクリプトを自動的に生成する可能性が増えています。ソースとターゲットに使用した変更セットを元に戻し、SQLCompareコマンドラインを起動するだけです。多機能ツールです。