適用対象:✅Microsoft Fabric の倉庫
この記事では、Microsoft Fabric のウェアハウスに対して Git 統合と展開パイプラインがどのように機能するのかを説明します。 リポジトリへの接続の設定、ウェアハウスの管理、さまざまな環境へのデプロイを行う方法について説明します。 現在、Fabric Warehouse 向けのソース管理はプレビュー機能です。
Git 統合と展開パイプラインの両方を、さまざまなシナリオに使用できます。
- Git と SQL データベース プロジェクトを使って、個々のデータベース オブジェクトの増分変更、チーム コラボレーション、コミット履歴を管理します。
- 展開パイプラインを使って、コードの変更を異なる運用前環境と運用環境にレベル上げします。
Git 統合
Microsoft Fabric の Git 統合を使うと、開発者は開発プロセス、ツール、ベスト プラクティスを Fabric プラットフォームに直接統合できます。 Fabric で開発している開発者は、次のことができます。
- 作業のバックアップとバージョン管理
- 必要に応じて前のステージに戻す
- Git ブランチを使用して他のユーザーと共同作業する、または単独で作業する
- 使い慣れたソース管理ツールの機能を適用して、Fabric アイテムを管理する
Git 統合プロセスについて詳しくは、以下をご覧ください。
ソース管理への接続を設定する
[ワークスペース設定] ページから、変更をコミットして同期するためのリポジトリへの接続を簡単に設定できます。
- 接続を設定するには、「Git 統合での作業開始」を参照してください。 手順に従い、Git プロバイダーとして Azure DevOps または GitHub を使って、Git リポジトリに接続します。
- 接続すると、ウェアハウスなどの項目が [ソース管理] パネルに表示されます。
- ウェアハウス インスタンスを Git リポジトリに正常に接続すると、リポジトリ内のウェアハウスのフォルダー構造が表示されます。 これで、pull request の作成などの操作をさらに実行できるようになります。
Git でのウェアハウス用のデータベース プロジェクト
次の画像は、リポジトリ内の各ウェアハウス項目のファイル構造の例です。
ウェアハウス項目を Git リポジトリにコミットすると、ウェアハウスが SQL データベース プロジェクトとしてソース コード形式に変換されます。 SQL プロジェクトは、テーブル、ストアド プロシージャ、関数など、単一データベースのスキーマを構成する SQL オブジェクトをローカルで表現したものです。 データベース オブジェクトのフォルダー構造は、スキーマとオブジェクトの種類で編成されます。 ウェアハウス内の各オブジェクトは、データ定義言語 (DDL) 定義を含む .sql ファイルで表されます。 ウェアハウス テーブルのデータと SQL セキュリティ機能は、SQL データベース プロジェクトには含まれません。
共有クエリもリポジトリにコミットされ、保存に使われている名前を継承します。
デプロイ パイプライン
展開パイプラインを使って、開発、テスト、運用などのさまざまな環境に、ウェアハウスのコードを展開することもできます。 展開パイプラインでは、データベース プロジェクトは公開されません。
展開パイプラインを使ってウェアハウスの展開を行うには、次の手順のようにします。
- 新しいデプロイ パイプラインを作成するか、既存のデプロイ パイプラインをオープンします。 詳しくは、「展開パイプラインの使用を開始する」をご覧ください。
- デプロイの目標に応じて、ワークスペースをさまざまなステージに割り当てます。
- 次の例で示すように、異なるステージの間で、ウェアハウスなどの項目を選択、表示、比較します。
- [展開] を選んで、[開発]、[テスト]、[運用] の各ステージにウェアハウスを展開します。
Fabric デプロイ パイプライン プロセスの詳細については、「 デプロイ パイプラインの概要」を参照してください。
ソース管理の制限事項
- SQL セキュリティ機能は、スクリプトベースのアプローチを使ってエクスポートまたは移行する必要があります。 配置後のスクリプトを SQL データベース プロジェクトで使用することを検討してください。このスクリプトは、Visual Studio Code で使用できる SQL Database Projects 拡張機能を使用してプロジェクトを開くことで構成できます。
Git 統合の制限事項
- 現在、データベース プロジェクトで
ALTER TABLEを使って制約または列を追加すると、展開時にテーブルが削除されて再作成され、データが失われます。 テーブルの定義とデータを保持するには、次の回避策を検討してください。-
CREATE TABLEとINSERT、CREATE TABLE AS SELECT、またはテーブルの複製を使って、ウェアハウス内にテーブルの新しいコピーを作成します。 - 必要に応じて、
ALTER TABLEを使い、新しい制約または列で新しいテーブル定義を変更します。 - 古いテーブルを削除します。
- sp_rename を使って、新しいテーブルの名前を古いテーブルの名前に変更します。
- "まったく" 同じ方法で、SQL データベース プロジェクト内の古いテーブルの定義を変更します。 ソース管理内のウェアハウスの SQL データベース プロジェクトとライブ ウェアハウスが一致するようになるはずです。
-
- 現時点では、ウェアハウスへの出力先を含む Dataflow Gen2 を作成しないでください。 Git からのコミットと更新は、リポジトリに存在する
DataflowsStagingWarehouseという名前の新しい項目によってブロックされます。 - Fabric Git 統合では、SQL 分析エンドポイント項目はサポートされていません。
- SQL 分析エンドポイントとウェアハウスの間の項目間の依存関係、項目のシーケンス、および同期のギャップは、開発と継続的インテグレーションの間の "新規/既存のワークスペースへの分岐" および "別のブランチへの切り替え" ワークフローに影響します。
展開パイプラインの制限事項
- 現在、データベース プロジェクトで
ALTER TABLEを使って制約または列を追加すると、展開時にテーブルが削除されて再作成され、データが失われます。 - 現時点では、ウェアハウスへの出力先を含む Dataflow Gen2 を作成しないでください。 展開は、展開パイプラインに存在する
DataflowsStagingWarehouseという名前の新しい項目によってブロックされます。 - ファブリック デプロイ パイプラインは、SQL 分析エンドポイント項目をサポートしていません。
- 項目間の依存関係、項目のシーケンス、および SQL 分析エンドポイントとウェアハウス間の同期ギャップは、Fabric Deployment Pipelines ワークフローに影響します。