展開計画の例(プレビュー)

この記事では、展開計画が一般的に使われるパターンを示しています。 それぞれが展開グループとそれに付随するアクションを説明しているので、キャンバス上で同等のものを構築できます。

計画の立て方については、「 展開計画を作成」をご覧ください。

別のアイテムが生成するデータに依存しているアイテムを展開する

これがプランを利用する最も一般的な理由です。

ワークスペース

営業チームは、分析ソリューションを4つの項目を含む単一のgit接続ワークスペースにまとめています。

なぜ配備順序だけでは不十分なのか

Fabricはアイテム系譜を使って倉庫ビューがレイクハウステーブルを参照していることを検出し、倉庫より先にレイクハウスを展開します。

リネージは、ビューが有効になる前にテーブルを 埋め なければならないとは示していません。 項目定義付きのテーブルは表示されません。 2つのノートブックは実行時にこれを生成します:

計画なしでこのワークスペースを展開すると、展開は失敗します。 すべてのアイテムは正しくコピーされていますが、ウェアハウスビューは誰もまだ作成していないテーブルに対して作成されており、デプロイメントではオブジェクト名が無効であると報告されます。 目標は部分的に展開されたままです。

アイテム自体に問題はありません。 欠けているのは、レイクハウスの展開と倉庫の展開の間にノートブックを動かす指示です。 その指示が計画です。

計画

計画には2つの展開グループがあり、1つは湖畔ハウス用、もう1つは倉庫用です。 Lakehouseグループは両方のノートブックをデプロイ後のアクションとして実行しています:

レイクハウスが展開された後、 Hydrate_TopCustomers はソースの行を書き込みます。 その後Publish_TopCustomersdbo.top_customersを作成し、SQL分析エンドポイントがテーブルを公開するまで待ちます。 レイクハウスグループは両方のアクションが終わった後に終了します。 その後、Fabricはウェアハウスを展開し、ビューを作成できます。

ノートブックはレイクハウスグループ内のアクションであり、別々のデプロイグループではありません。 Publish_TopCustomers Hydrate_TopCustomersによりますし、倉庫グループは完成したレイクハウスグループに依存します。

同じ設計図がキャンバスに描かれています:

plan.yml構造を理解する

キャンバスの上に計画を立てる。 ワークスペースがGitに接続されると、プランはデプロイメントの項目フォルダ内の plan.yml ファイルとして保存されるため、他の項目と同様にレビューとバージョン管理が行われます:

$schema: https://developer.microsoft.com/json-schemas/fabric/item/deploymentPlan/definition/plan/1.0.0/schema.json
version: 1.0.0
groups:
  - name: Sales_Lakehouse
    logicalId: 11111111-1111-1111-1111-111111111111
    postActions:
      - name: Run Hydrate_TopCustomers
        job:
          type: Execute
          logicalId: 22222222-2222-2222-2222-222222222222
      - name: Run Publish_TopCustomers
        dependsOn:
          - actionName: Run Hydrate_TopCustomers
        job:
          type: Execute
          logicalId: 33333333-3333-3333-3333-333333333333
  - name: Sales_Warehouse
    logicalId: 44444444-4444-4444-4444-444444444444
    dependsOn:
      - groupName: Sales_Lakehouse

ファイルの構造は次のとおりです。

この定義で注意すべき点がいくつかあります:

• グループが1つのアイテムを挙げます。 logicalId はアイテムの論理IDであり、Git統合が使う同じ識別子なので、アイテムがワークスペース間を移動してもプランは有効性を保ちます。
• グループの順序はファイル内の位置ではなくdependsOnで表現されます。 ファイル内のグループの並べ替えは何も変わりません。
• 行動順序も dependsOnで表現されます。 Run Publish_TopCustomersはRun Hydrate_TopCustomersが完了してから開始されます。
• postActions グループのアイテムが展開された後に走りましょう。 検証チェックなど、まず行う必要がある作業には preActions を使いましょう。

展開後にコンテンツを更新してください

デプロイメントはアイテム定義を更新します。 何も実行しないので、セマンティックモデルやレポートは新しい定義を反映しますが、新しいデータは反映されません。

この計画をデプロイメントパイプラインのデプロイメントに結びつけ、段階に昇格してもターゲットがすぐに使えるようにし、手動でリフレッシュする必要がなくなります。

デプロイする前に必ず検証してください

プレデプロイアクションはグループのアイテムが展開する前に実行されるので、そのうちの一つをゲートとして使うことができます。

アクションはすでに展開されているアイテムのみ実行できるため、チェック自体は先のグループによって展開されます:

チェックに失敗すると展開は停止し、そのグループに依存するものは一切展開されません。 これを使って、接続が解決されているか、必要な容量が稼働しているか、またはリリース開始前にソースシステムが利用可能かを確認します。

リネージで確認できない作業を順序付けする

2つのアイテムは系譜的に完全に独立していても、注文が必要な場合もあります。 計画とは、それを表現する方法です。

依存関係はアイテム参照ではなく接続を通じて行われるため、Fabricはそれを推測できません。 計画が秩序を供給します。

関連するコンテンツ

• デプロイメントプランとは何ですか?
• 展開計画を作成する
• 展開計画の行動
• デプロイ計画のトラブルシューティング