適用対象: Microsoft Fabric のウェアハウス✅
Microsoft Fabricパイプラインは、Dev、→Test、Production→など、ワークスペース間でウェアハウススキーマを効率的に変更する手段を提供します。 パイプラインには依存関係処理、スキーマ検証、宣言型デプロイメントインテリジェンスが組み込まれています。
Important
この機能は プレビュー段階です。
この記事では、パイプラインを用いた倉庫展開プロセスについて説明します。
デプロイメントパイプラインは、倉庫の変更を安全にワークスペース間で移動させるために必要なライフサイクル構造を提供します。 これらはスキーマプロモーションの中央オーケストレーションレイヤーとして機能し、チームがアドホック展開に頼らずに分析プラットフォーム上での変更の流れを標準化できるようにします。 一度作成されると、パイプラインは倉庫の比較、変更のレビュー、デプロイの実行のための主要なインターフェースとなります。
パイプラインを作成する
新しいパイプラインを作成するには、「 デプロイメントパイプラインの始め 方」をご覧ください。
比較
展開前には必ずT-SQLの変更点を確認し比較してください。 デプロイメントパイプラインは、Fabricポータル内で影響を受けたウェアハウスオブジェクトを簡単に確認できる比較画面を提供します。
変更を確認することで、チームは下流環境へのアップデートを推進する前に準備状況を検証できます。 このプロセスは、複数のチームが倉庫開発に協力するエンタープライズのシナリオで特に価値があります。
Fabricはこの比較のためにDacFx(データ層アプリケーションフレームワーク)を使用しています。 DacFxは両方の環境の宣言的スキーマモデルを構築し、新しいテーブル、変更された列、制約、依存関係の変更などの違いを識別します。 この比較はモデル駆動型であるため、展開時に起こることを正確に反映しています。
Important
スキーマ比較が機能するためには、ウェアハウスがソースワークスペースとターゲットワークスペースの両方に存在しなければなりません。 もしターゲットワークスペースにまだウェアハウスが含まれていなければ、まず初期のベースラインバージョンを作成またはデプロイしてください。
Note
もしある列の COLLATE 節が倉庫のデフォルトの集合と明示的に同じ集計を指定している場合、比較は違いとして表示されません。なぜなら、それは集計を指定しないのと同じだからです。 倉庫のデフォルトの集計と異なる列のみが、集計が変更された際に比較に表示されます。 詳細および例については、「Fabric Data Warehouse開発のためのTroubleshoot Git統合」をご覧ください。
変更を展開する前に、デプロイパイプラインの比較機能を活用して、ソースとターゲットのウェアハウスワークスペースの違いを確認してください。
「 比較 」を選択して変更点を確認できます。例えば、倉庫内で新しいビューを作成することなどです:
Deploy
比較が完了し変更を検証した後、パイプラインインターフェースから直接展開し、プロモーションする倉庫アイテムを選択できます。
デプロイメント中、デプロイメントパイプラインはDacFxを使ってスキーマの違いに基づくインテリジェントなデプロイメントプランを生成します。 Fabricはターゲットワークスペースをソースと同期させるために必要な変更のみを適用します。
展開構成
Fabric展開パイプラインは、Fabric Data Warehouse向けに特化した構成を持つDacFx展開技術を使用しています。 これらの構成により、Fabricプラットフォームの機能や運用慣行に沿った信頼性のある展開が成功します。
データ損失のブロック(
BlockOnPossibleDataLoss = true) - Fabric Data Warehouseは、ユーザーデータの切り捨てや削除、その他の損失を防ぐデプロイメントを防ぎます。 この設定により、高リスクのスキーマ変更がCI/CDを通過するのを防ぎ、データ損失のリスクを無言のデフォルトではなく意図的な判断にします。データベースレベルのオプションスクリプトをスキップする(
ScriptDatabaseOptions = false) - Fabricプラットフォームレベルで多くのデータベースレベルの設定を管理します。 デプロイ中のスクリプト文のようなALTER DATABASE ... SETは、失敗や意図しない設定ドリフトを引き起こすことがあります。 したがって、デプロイメントパイプラインはこれらの設定の伝播を避け、スキーマ展開がサポートされるウェアハウスオブジェクトのみに焦点を当てるようにします。レプリケートオブジェクト(
DoNotAlterReplicatedObjects = false)のエンジン強制を可能にする - ウェアハウスはリンクや同期シナリオなどで内部レプリケーション機構をよく利用します。 スキーマの変更を早期にブロックする代わりに、デプロイメントパイプラインによりFabricエンジンが変更の許可を判断できます。 このアプローチは、不必要な展開失敗を防ぎつつ、プラットフォームのセーフガードを維持します。トランザクション型DDLスクリプトの無効化(
IncludeTransactionalScripts = false) - 現在、ウェアハウスはトランザクション内でDDLスクリプトをラップするサポートをしていません。 したがって、デプロイメントパイプラインは非トランザクションスクリプトを生成し、展開が成功裏に完了できるようにします。スキーマ進化のためのインテリジェントデフォルト(
GenerateSmartDefaults = true)の活用 - スキーマの変更により、null可能なカラムを非nullableに変換したり、デフォルト制約を持つ新しいカラムを追加したりといった厳格な制約が導入されると、デプロイメントパイプラインは自動的にベースライン値を入力できます。 このアプローチにより、手動のデータ準備を必要とせずに展開が成功し、スキーマ進化時の運用上の摩擦も軽減されます。セキュリティプリンシパルのデプロイメントからの除外(
ExcludeObjectTypes = Logins, Users, Permissions) - セキュリティオブジェクトはウェアハウス展開から意図的に除外されます。 ログイン、ユーザー、権限を環境間でプロポーズすると、セキュリティリスクや環境固有の競合が生じる可能性があります。 代わりに、アクセス制御は環境ガバナンスやアイデンティティ管理プロセスを通じて別途管理してください。ソースにないオブジェクトをドロップしない(
DropObjectsNotInSource = false) - ターゲットに存在するがソースにないオブジェクトは自動的にドロップされません。 生産とソース管理を完全に同期させるウェアハウスは、これを制限するかもしれません。
Limitations
- デフォルトでは、システムはテーブルドロップをブロックします。 デプロイプロセスは、ターゲットには存在するがソースには存在しないオブジェクトを自動的にドロップするわけではありません。 この設計により、偶発的なデータ損失を減らし、本番環境での予期せぬ削除を防ぎます。
- 導入が成功したからといって、すべてのリクエスト変更が適用されたとは限りません。 デプロイメントは、テーブルドロップがデフォルトでブロックされているため、リクエストされたドロップテーブルアクションをスキップしても成功を報告できます。 その場合、デプロイ操作は完了しますが、ターゲットはソース管理から離れ、明示的に変更が解除されるまでは問題が出ません。
- 現在、デプロイプロセスは厳密なソースパリティよりも安全性を優先しており、ターゲットにのみ存在するオブジェクトは除外しません。
- Fabricデプロイ パイプラインでは、SQL 分析エンドポイント項目はサポートされていません。
- 項目間の依存関係、項目のシーケンス、および SQL 分析エンドポイントとウェアハウス間の同期ギャップは、Fabric Deployment Pipelines ワークフローに影響します。
- Fabric Data Warehouseのデプロイメントパイプラインで関連項目を選択することはサポートされていません。
Git 統合のトラブルシューティング
Git統合に特有の制限については、Git統合の記事にある 「Git統合の制限 」を参照してください。
トラブルシューティング、回避策、Fabric Data Warehouse開発における一般的なGit統合問題の修正については、「Troubleshoot Git integration for the the Fabric Data Warehouse development(開発のためのTroubleshoot Git統合)」をご覧ください。