パイプラインを使って倉庫を展開する

適用対象: Microsoft Fabric のウェアハウス✅

Microsoft Fabricパイプラインは、Dev、→Test、Production→など、ワークスペース間でウェアハウススキーマを効率的に変更する手段を提供します。 パイプラインには依存関係処理、スキーマ検証、宣言型デプロイメントインテリジェンスが組み込まれています。

Important

この機能は プレビュー段階です

この記事では、パイプラインを用いた倉庫展開プロセスについて説明します。

パイプライン展開ライフサイクルの図はFabric Data Warehouse。

デプロイメントパイプラインは、倉庫の変更を安全にワークスペース間で移動させるために必要なライフサイクル構造を提供します。 これらはスキーマプロモーションの中央オーケストレーションレイヤーとして機能し、チームがアドホック展開に頼らずに分析プラットフォーム上での変更の流れを標準化できるようにします。 一度作成されると、パイプラインは倉庫の比較、変更のレビュー、デプロイの実行のための主要なインターフェースとなります。

パイプラインを作成する

新しいパイプラインを作成するには、「 デプロイメントパイプラインの始め 方」をご覧ください。

比較

展開前には必ずT-SQLの変更点を確認し比較してください。 デプロイメントパイプラインは、Fabricポータル内で影響を受けたウェアハウスオブジェクトを簡単に確認できる比較画面を提供します

変更を確認することで、チームは下流環境へのアップデートを推進する前に準備状況を検証できます。 このプロセスは、複数のチームが倉庫開発に協力するエンタープライズのシナリオで特に価値があります。

Fabricはこの比較のためにDacFx(データ層アプリケーションフレームワーク)を使用しています。 DacFxは両方の環境の宣言的スキーマモデルを構築し、新しいテーブル、変更された列、制約、依存関係の変更などの違いを識別します。 この比較はモデル駆動型であるため、展開時に起こることを正確に反映しています。

Important

スキーマ比較が機能するためには、ウェアハウスがソースワークスペースとターゲットワークスペースの両方に存在しなければなりません。 もしターゲットワークスペースにまだウェアハウスが含まれていなければ、まず初期のベースラインバージョンを作成またはデプロイしてください。

Note

もしある列の COLLATE 節が倉庫のデフォルトの集合と明示的に同じ集計を指定している場合、比較は違いとして表示されません。なぜなら、それは集計を指定しないのと同じだからです。 倉庫のデフォルトの集計と異なる列のみが、集計が変更された際に比較に表示されます。 詳細と例については、「Fabric Warehouse Development for Troubleshoot Git integration for the warehouse development」をご覧ください。

変更を展開する前に、デプロイパイプラインの比較機能を活用して、ソースとターゲットのウェアハウスワークスペースの違いを確認してください。

Fabricポータルでパイプラインを使って、2つの異なるワークスペースの倉庫を比較するスクリーンショットです。

比較 」を選択して変更点を確認できます。例えば、倉庫内で新しいビューを作成することなどです:

ある州の倉庫と別の州の倉庫を比較したスクリーンショットです。

Deploy

比較が完了し変更を検証した後、パイプラインインターフェースから直接展開し、プロモーションする倉庫アイテムを選択できます。

パイプライン内のこの段階にデプロイ画面のFabricポータルからのスクリーンショットです。

デプロイメント中、デプロイメントパイプラインはDacFxを使ってスキーマの違いに基づくインテリジェントなデプロイメントプランを生成します。 Fabricはターゲットワークスペースをソースと同期させるために必要な変更のみを適用します。

成功したデプロイメントのFabricポータルからのスクリーンショット。

展開構成

Fabric展開パイプラインは、Fabric Data Warehouse向けに特化した構成を持つDacFx展開技術を使用しています。 これらの構成により、Fabricプラットフォームの機能や運用慣行に沿った信頼性のある展開が成功します。

  • データベースレベルのオプションスクリプトをスキップする(ScriptDatabaseOptions = false) - Fabricプラットフォームレベルで多くのデータベースレベルの設定を管理します。 デプロイ中のスクリプト文のような ALTER DATABASE ... SET は、失敗や意図しない設定ドリフトを引き起こすことがあります。 したがって、デプロイメントパイプラインはこれらの設定の伝播を避け、スキーマ展開がサポートされるウェアハウスオブジェクトのみに焦点を当てるようにします。

  • レプリケートオブジェクトのエンジン強制(DoNotAlterReplicatedObjects = false)の許可 - Fabricウェアハウスはリンクや同期シナリオなどで内部レプリケーション機構をよく利用しています。 スキーマの変更を早期にブロックする代わりに、デプロイメントパイプラインによりFabricエンジンが変更の許可を判断できます。 このアプローチは、不必要な展開失敗を防ぎつつ、プラットフォームのセーフガードを維持します。

  • トランザクション型DDLスクリプトの無効化(IncludeTransactionalScripts = false) - 現在、Fabricウェアハウスはトランザクション内でDDLスクリプトをラップする機能をサポートしていません。 したがって、デプロイメントパイプラインは非トランザクションスクリプトを生成し、展開が成功裏に完了できるようにします。

  • スキーマ進化のためのインテリジェントデフォルト(GenerateSmartDefaults = true)の活用 - スキーマの変更により、null可能なカラムを非nullableに変換したり、デフォルト制約を持つ新しいカラムを追加したりといった厳格な制約が導入されると、デプロイメントパイプラインは自動的にベースライン値を入力できます。 このアプローチにより、手動のデータ準備を必要とせずに展開が成功し、スキーマ進化時の運用上の摩擦も軽減されます。

  • セキュリティプリンシパルのデプロイメントからの除外(ExcludeObjectTypes = Logins, Users, Permissions) - セキュリティオブジェクトはウェアハウス展開から意図的に除外されます。 ログイン、ユーザー、権限を環境間でプロポーズすると、セキュリティリスクや環境固有の競合が生じる可能性があります。 代わりに、アクセス制御は環境ガバナンスやアイデンティティ管理プロセスを通じて別途管理してください。

Limitations

  • Fabricデプロイ パイプラインでは、SQL 分析エンドポイント項目はサポートされていません。
  • 項目間の依存関係、項目のシーケンス、および SQL 分析エンドポイントとウェアハウス間の同期ギャップは、Fabric Deployment Pipelines ワークフローに影響します。
  • 一度に一つの倉庫を展開しましょう。 展開用に関連するアイテムの選択はサポートされていません。

Git 統合のトラブルシューティング

Git統合に特有の制限については、Git統合の記事にある 「Git統合の制限 」を参照してください。

Fabricウェアハウス開発における一般的なGit統合問題のトラブルシューティング、回避策、修正については、「Fabricウェアハウス開発のためのGit統合のトラブルシューティング」をご覧ください。