作業フォルダのソース管理を使用したデータベースの変更の追跡

この記事では、データベースに加えられた履歴の変更を追跡できるように、作業フォルダーを使用してデータベースをバージョン管理する新しい方法について説明します。

概要

この記事は、作業フォルダーの制限を克服することによってデータベースをソース管理する新しいアプローチに基づいているため、作業フォルダーと関連事項の基本的な理解を深めることをお勧めします。

背景

作業フォルダーをソース管理として使用する場合、データベースの変更の履歴を保持できないという制限があります。ただし、この記事では、制限を克服できる作業フォルダーで（舞台裏で）セカンダリソースコントロールを使用する方法に焦点を当てます。

前提条件

この記事は、読者がWorking FolderとGitを使用したデータベースバージョン管理の基本に精通し、現在AzureDevOpsと呼ばれているVisualStudioTeam Services（VSTS）を理解していることを前提としています。

この記事に記載されているすべての手順を実行するには、次の一連のツールを使用することをお勧めします。

dbForge for SQL Server
dbForgeソース管理
Git for Windows（または任意のGitクライアント）
Azure DevOps（以前のVSTS）

この記事では、Azure DevOpsにサインアップして既にアカウントを取得していることも前提としています。この記事のすべての手順を実行する場合は、今すぐサインアップして新しいアカウントを作成できます。

または、この記事の概念的なアプローチを実行に移すために必要なスキルがあれば、Working Folderオプションを提供するソース管理をSSMS（SQL Server Management Studio）で使用できます。

リファレンス

作業フォルダを使用して管理データベースをソース管理するための基本的な理解を深めるために、以下のリンクをクリックして、以前の記事を読んでください。

作業フォルダを使用して簡単な手順で管理データベースを調達する

作業フォルダの制限

まず、WorkingFolderを使用してデータベースをソース管理することの制限を理解する必要があります。私の以前の記事を読んだことがあるなら、あなたはすでに制限を知っています。

作業フォルダのシナリオ

次の手順を注意深く観察すると、データベースのバージョン管理に関して、作業フォルダのソース管理オプションがどのように制限されているかを簡単に理解できます。

Dev1は、腕時計に関する新しいデータベースを作成し、それを時計と呼びます。要件に応じて。
Dev1はさらに新しいテーブルを作成し、それを監視と呼びます WatchId およびWatchName 要件に応じた列。
Dev1は特定のソース管理を使用するように求められておらず、プロジェクト自体が開発テスト段階にあるため、WorkingFolderソース管理を使用することにしました。
Dev2は新しいテーブルを作成するように依頼されましたDigitalWatch DigitalWatchId 列を削除してウォッチを削除します DigitalWatchでそれを考えているテーブルテーブルウォッチ テーブルはもう必要ありません。
Dev2によって行われた変更を元に戻して、ウォッチを作成する方法はありません。作業フォルダに最新バージョンのデータベースコードが追加されたため、作業フォルダのソース管理をもう一度使用するテーブル。

これは次のように示されています：

作業フォルダを使用したデータベースの変更の追跡

作業フォルダを強制してデータベースの変更を追跡する方法があります。これにより、失われたデータベースオブジェクトを復元できますが、デフォルトで作業フォルダを使用すると、データベースの変更の履歴は保持されません。

二次ソース管理（Git）の使用

これは、管理が少し複雑ですがうまく機能する作業フォルダオプションを使用するとともに、セカンダリソース管理を使用することで実現できます。

この記事では、作業フォルダーを使用したセカンダリソース管理としてGitを使用します。

Gitは分散バージョン管理システムであり、今日最も一般的に使用されているソース管理の1つでもあります。

なぜWorkingFolderでGitするのですか？

データベースのバージョン管理にdbForgeStudiofor SQL ServerでGitを直接使用できるのに、なぜGitをWorkingFolderと並べて使用する必要があるのかという議論があります。

答えは、作業フォルダのソース管理オプションの柔軟な性質を理解するとともに、作業フォルダを一時的な解決策として使用するのではなく、作業フォルダを継続する可能性を探ることです。

任意のGitソース管理クライアントまたはGitforWindowsをダウンロード

先に進む前に、データベースの変更を時間の経過とともに保存するのに役立つ、選択したGitソース管理クライアントをインストールしてください。

この記事のウォークスルーでは、GitforWindowsクライアントを使用しています。

選択したオプションを使用してGitforWindowsをインストールします。デフォルトのオプションを使用してGitforWindowsをインストールしました。

Gitを使用してAzureDevOpsプロジェクトを作成する

Azure DevOpsアカウントにサインインして、新しいプロジェクトを作成します SQLBookShopV3-Using-Working-Folder-with-Git Gitを選択します次のようにプライベートリポジトリを作成するためのソース管理オプション。

リポジトリに移動します左側のナビゲーションバーで、リンクの横にあるクリップボードアイコンをクリックして、リポジトリ（Gitリポジトリ）リンクをコピーします。

計画は、Gitリポジトリリンクに基づいてローカルリポジトリを作成し、これを介してワーキングフォルダに権限を与えることです。

Gitローカルリポジトリの下に作業フォルダーを作成

すでにGitLocalReposフォルダーがある場合は、作業フォルダーを作成します SQLBookShopV3-Working-Folder-with-Git そこに：

C：\ Users \ \ Source \ Repos \ SQLBookShopV3-Working-Folder-with-Git

または、リポジトリを作成します任意の場所にフォルダーを作成してから、サブフォルダーSQLBookShopV3-Working-Folder-with-Git。を作成します。

新しいGitローカルリポジトリを作成する

次に、ローカルGitリポジトリを作成して、作業フォルダーがそのリポジトリに収まるようにします。

Git GUIを開きます Git for Windowsの後に存在する必要がありますインストール。

新しいリポジトリの作成を選択して、ローカルリポジトリを作成しますオプション。

Gitローカルリポジトリ（リポジトリ）を作成します。

ローカルのGitリポジトリが正常に作成されました。

リモートGitリポジトリとローカルリポジトリをリンクする

Gitローカルリポジトリを作成するだけでは不十分です。AzureDevOpsを介して作成したGitリモートリポジトリとリンクしています。

リモートを選択して、リモートGitリポジトリをGitローカルリポジトリにリンクしますメインメニューからオプションを選択し、[新しいリモートの追加]をクリックします次に、AzureDevOpsプロジェクトの場所を入力します。

SQLBookShopV3データベースの作成

dbForge Studio for SQL Serverを開き、新しいデータベース SQLBookShopV3を作成します。

ブックテーブルの作成

本を作成する次のように、BookId、Title、およびAuthor列を持つテーブル。

CREATE TABLE SQLBookShopV3.dbo.Book (
  BookId INT IDENTITY
 ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId)
 ,Title VARCHAR(100)
 ,Author VARCHAR(50)
)
GO

データベースと作業フォルダのソース管理をリンクする

次のステップでは、データベースを作業フォルダのソース管理にリンクします。

データベース（SQLBookShopV3）を右クリックし、ソース管理を選択します、次にデータベースをソース管理にリンク 。

次に、前に作成した作業フォルダを見つけてデータベースにリンクします。

作業フォルダへの変更のコミット

ソース管理マネージャーに移動します確認してください（コミット ）新しく作成された本テーブルを作業フォルダのソース管理に追加します。

作業フォルダをチェックして、本を確認してくださいそこにテーブルがあります。

Gitソース管理（ブックテーブル）への変更のプッシュ

Git GUIを開きますもう一度[再スキャン]をクリックしますテーブルオブジェクトを表示するボタンをクリックし、次の初期コミットを追加します。

初期コミット（Bookテーブルが最初に作成された）

次に、次の手順を実行します。

ステージの変更
変更をコミットする
プッシュ（変更）

または、GitBashを使用してコマンドラインからGitを実行することもできます。

Gitソース管理にコミットされた変更の表示

Azure DevOpsに移動しますすでに署名されている場合のウェブページとSQLBookShopV3-Using-Working-Folder-with-Gitプロジェクト アクティブです。

リポジトリをクリックします左側のナビゲーションバーで、Gitソース管理にコミットされたばかりの変更を表示します。

次に、テーブルスクリプトを確認します。

株価と価格の列を追加

次に、さらに2つの列を追加しますストック および価格本へ次のスクリプトを使用してテーブルを作成します。

CREATE TABLE SQLBookShopV3.dbo.Book (
  BookId INT IDENTITY
 ,Title VARCHAR(100) NULL
 ,Author VARCHAR(50) NULL
 ,Price DECIMAL(8, 2) NULL
 ,Stock SMALLINT NULL
 ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId)
) ON [PRIMARY]
GO

で

表は次のようになります。

作業フォルダへの変更のコミット

以下に示すように、2つの追加列を含むBookテーブルの最新の定義をWorking FolderSourceControlに保存します。

Windowsエクスプローラーを使用して作業フォルダーを見つけ、メモ帳でdbo.table.sqlを開いて、コードを確認します。

作業フォルダには、テーブルの最新の定義が含まれており、テーブルの最初の形状に関する情報は提供されません。

すでに説明したように、これは作業フォルダの制限であり、データベースの最新バージョンのみが表示され、新しいバージョンで上書きされるため、（データベースの変更）履歴をさかのぼる余地がありません。

Gitソース管理へのプッシュ変更（株価と価格の列）

次のステップでは、以下に示すように、テーブルの新しく追加された列をGitリモートリポジトリにプッシュします。

Gitソース管理を使用したデータベースの変更のトレース

これまでに、次の順序で2つの主要なデータベース変更を行いました。

本テーブルは、BookId、Title、およびAuthor列を使用して作成されました
価格と在庫の列が本に追加されましたテーブル

ブックテーブルが元々WorkingFolderを使用して作成された場合、最初の変更を確認する方法はありません。

ただし、Gitリモートリポジトリに変更をプッシュしている限り、Gitを使用してデータベースの変更のすべての履歴を表示することは可能です。

Azure DevOpsで、[プッシュ]をクリックしてください左側のナビゲーションバーで、データベースの過去の変更を確認できます。

コミットに移動しますデータベースの変更の順序をコミットの形式で表示します。

最初のコミットa99df4b5をクリックします本の最初の定義を確認するテーブル。

戻って次のコミットをクリックします6f863f0a 次のデータベースの変更を確認します。

おめでとう！セカンダリソース管理（Git）を備えたWorking Folderを使用して、データベースの変更を正常に追跡しました。

これで、必要に応じてテーブルの最初のバージョンに戻すか、データベースオブジェクトを追加し続けることができます。

やるべきこと

データベースオブジェクトを作業フォルダのソース管理下に置くだけでなく、データベースの履歴を維持することで、データベースのすべての変更を追跡できるようになりました。

本をリンクして別のデータベースを作成してみてください BookTypeのテーブル BookTypeId BookTypeの主キーテーブルはBookTypeIdとして渡されます本の外部キー列テーブルを作成し、作業フォルダのソース管理を使用してデータベースの変更を追跡します。
時計を作成してみてください記事の最初の図に示されているようにデータベースを作成し、Gitを使用したWorkingFolderを使用してデータベースの変更履歴を維持する手順に従います。
Dev2が誤ってウォッチを削除した場合は、記事の最初の図に記載されている変更を元に戻してみてください。データベースの変更を追跡するためにWorkingFolderを使用してDev1によって作成されたテーブル。

便利なツール：

dbForgeソース管理–ソース管理でSQLServerデータベースの変更を管理するための強力なSSMSアドイン。