ソース管理 (プレビュー)

適用対象:✅ Microsoft Fabric の倉庫

この記事では、Microsoft Fabric内のウェアハウスに対して Git 統合とデプロイ パイプラインがどのように機能するかについて説明します。 リポジトリへの接続の設定、ウェアハウスの管理、さまざまな環境へのデプロイを行う方法について説明します。 現在、Fabric Warehouse のソース管理はプレビュー機能です。

Git 統合展開パイプラインの両方を、さまざまなシナリオに使用できます。

  • Git および SQL データベース プロジェクトを使用して、個々のデータベース オブジェクトの増分変更、チームコラボレーション、コミット履歴を管理します。
  • 展開パイプラインを使って、コードの変更を異なる運用前環境や運用環境にプロモートします。

Git 統合

Microsoft Fabricでの Git 統合により、開発者は開発プロセス、ツール、ベスト プラクティスをFabric プラットフォームに直接統合できます。 これにより、Fabricで開発している開発者は次のことができます。

  • 作業をバックアップし、バージョン管理する
  • 必要に応じて前のステージに戻す
  • Git ブランチを使用して他のユーザーと共同作業を行うか、単独で作業する
  • 使い慣れたソース管理ツールの機能を適用してFabric項目を管理する

Git 統合プロセスについて詳しくは、以下をご覧ください。

ソース管理への接続を設定する

[ワークスペース設定] ページから、変更をコミットして同期するためのリポジトリへの接続を簡単に設定できます。

  1. 接続を設定するには、「Git 統合での作業開始」を参照してください。 手順に従って Git プロバイダーとして Git リポジトリに接続 し、Azure DevOps または GitHub に接続します。
  2. 接続すると、ウェアハウスなどの項目が [ソース管理] パネルに表示されます。 ソース管理設定の倉庫のFabricポータルからのスクリーンショット。
  3. ウェアハウス インスタンスを Git リポジトリに正常に接続すると、リポジトリ内のウェアハウスのフォルダー構造が表示されます。 これで、pull request の作成などの操作をさらに実行できるようになります。

Git でのウェアハウス用のデータベース プロジェクト

次の画像は、リポジトリ内の各ウェアハウス項目のファイル構造の例です。

サンプル ウェアハウス スキーマのFabric ポータルからのスクリーンショット。

ウェアハウス項目を Git リポジトリにコミットすると、ウェアハウスが SQL データベース プロジェクトとしてソース コード形式に変換されます。 SQL プロジェクトは、テーブル、ストアド プロシージャ、関数など、単一データベースのスキーマを構成する SQL オブジェクトをローカルで表現したものです。 データベース オブジェクトのフォルダー構造は、スキーマとオブジェクトの種類で編成されます。 ウェアハウス内の各オブジェクトは、データ定義言語 (DDL) 定義を含む .sql ファイルで表されます。 ウェアハウス テーブル データと SQL セキュリティ機能 は、SQL データベース プロジェクトには含まれません。

共有クエリもリポジトリにコミットされ、保存に使われている名前を継承します。

デプロイ パイプライン

展開パイプラインを使って、開発、テスト、運用などのさまざまな環境に、ウェアハウスのコードを展開することもできます。 展開パイプラインでは、データベース プロジェクトは公開されません。

次の手順を使用して、デプロイ パイプラインを使用してウェアハウスのデプロイを完了します。

  1. 新しいデプロイ パイプラインを作成するか、既存のデプロイ パイプラインをオープンします。 詳しくは、「展開パイプラインの使用を開始する」をご覧ください。
  2. デプロイの目標に応じて、ワークスペースをさまざまなステージに割り当てます。
  3. 次の例に示すように、異なるステージ間で倉庫を含む品目を選択、表示、比較します。 開発、テスト、運用の各ステージのFabric ポータルからのスクリーンショット。
  4. [展開] を選んで、[開発][テスト][運用] の各ステージにウェアハウスを展開します。

Fabricデプロイ パイプライン プロセスの詳細については、「デプロイ パイプラインの概要」を参照してください。

ソース管理の制限事項

Git 統合の制限事項

  • 現在、 ALTER TABLE を使用してデータベース プロジェクトに制約または列を追加すると、配置プロセスによってテーブルが削除されて再作成され、データが失われます。 テーブルの定義とデータを保持するには、次の回避策を検討してください。
    • CREATE TABLEINSERTCREATE TABLE AS SELECT、または Clone テーブルを使用して、ウェアハウスにテーブルの新しいコピーを作成します。
    • ALTER TABLEを使用して、必要に応じて新しい制約または列で新しいテーブル定義を変更します。
    • 古いテーブルを削除します。
    • sp_renameを使用して、新しいテーブルの名前を古いテーブルの名前に変更します。
    • "まったく" 同じ方法で、SQL データベース プロジェクト内の古いテーブルの定義を変更します。 ソース管理内のウェアハウスの SQL データベース プロジェクトとライブ ウェアハウスが一致するようになるはずです。
  • 現時点では、ウェアハウスへの出力先を含む Dataflow Gen2 を作成しないでください。 DataflowsStagingWarehouseという名前の新しい項目がリポジトリに表示され、Git からのコミットと更新がブロックされます。
  • Fabric Git 統合では、SQL 分析エンドポイント項目はサポートされていません。
  • SQL 分析エンドポイントとウェアハウス間の項目間の依存関係、項目のシーケンス、同期のギャップは、開発と継続的インテグレーションの間の "新規または既存のワークスペースへの分岐" ワークフローと "別のブランチへの切り替え" ワークフローに影響します。

展開パイプラインの制限事項

  • 現在、 ALTER TABLE を使用してデータベース プロジェクトに制約または列を追加すると、配置プロセスによってテーブルが削除されて再作成され、データが失われます。
  • 現時点では、ウェアハウスへの出力先を含む Dataflow Gen2 を作成しないでください。 DataflowsStagingWarehouseという名前の新しい項目がデプロイ パイプラインに表示され、デプロイがブロックされます。
  • Fabricデプロイ パイプラインでは、SQL 分析エンドポイント項目はサポートされていません。
  • 項目間の依存関係、項目のシーケンス、および SQL 分析エンドポイントとデータウェアハウスの間の同期ギャップは、Fabricのデプロイメントパイプラインワークフローに影響します。

サポートされていないシナリオ

異なるワークスペース内のウェアハウスの照合順序が異なる場合、次の CI/CD ワークフローは公式にはサポートされません。 これらの操作はエラーなしで成功する可能性がありますが、メタデータ エラーが発生する可能性があります。

これらのすべてのシナリオで照合順序の不一致が発生した場合は、Fabric ツールボックスの Python スクリプト scripts/dw-collation-error-update-tmsl/pbi_interactive.py GitHub リポジトリを使用して、ウェアハウスの照合順序と一致するようにデータセット (TMSL) 照合順序を更新します。

シナリオ 説明 リスク
デプロイメントパイプライン ソースとは異なる照合順序でターゲット ウェアハウスが作成されたパイプライン ステージ (Dev → Test → Prod など) を介してウェアハウス コンテンツを昇格することはサポートされていません。 デプロイは成功する可能性がありますが、データセットの照合順序は、ターゲット ウェアハウスの照合順序と一致するように更新されません。
新規または既存のワークスペースへの分岐 Git 統合を使用して、既存のワークスペースから、異なる照合順序を持つ新規または既存のデータベースに分岐することはサポートされていません。 ウェアハウスのコンテンツは同期されていますが、照合メタデータは整合されていません。
ワークスペースでのブランチの切り替え Git に接続されたワークスペース上の別の照合順序のウェアハウスに関連付けられたブランチへの切り替えはサポートされていません。 同期されたコンテンツは、現在のウェアハウスと一致しない照合順序の前提条件を引き継ぐ可能性があります。
ブランチを介してワークスペース間の変更をマージする ウェアハウスの照合規則が異なるワークスペース間での Git ブランチのマージはサポートされていません。 マージは Git レベルで成功する可能性がありますが、結果のデータセットの照合順序にはターゲット ウェアハウスの照合順序が反映されません。