次の方法で共有

Power BI の実装計画: コンテンツをデプロイする

  • [アーティクル]

手記

この記事は、Power BI 実装計画 一連の記事の一部です。 このシリーズでは、主に、Microsoft Fabric内の Power BI エクスペリエンスに焦点を当てます。 シリーズの概要については、Power BI 実装計画 参照してください。

この記事は、コンテンツライフサイクルの管理の一環としてコンテンツを展開するのに役立ちます。 これは主に次を対象とします。

  • Fabric 管理者: 組織内の Fabric の監督を担当する管理者。 ファブリック管理者は、Microsoft 365 や Azure DevOps を監督する管理者など、他の管理者と共同作業する必要がある場合があります。
  • センター オブ エクセレンス (COE) チームと BI チーム: 組織内の Power BI の監督を担当するチーム。 これらのチームには、Power BI コンテンツのライフサイクルを管理する方法を決定する意思決定者が含まれます。 これらのチームには、コンテンツ リリースのライフサイクルを処理するリリース マネージャーや、ライフサイクル管理を効果的に使用およびサポートするために必要なコンポーネントを作成および管理するエンジニアも含めることができます。
  • コンテンツ作成者とコンテンツ所有者: 他のユーザーと共有するために Fabric ポータルに発行するコンテンツを作成するユーザー。 これらの個人は、作成する Power BI コンテンツのライフサイクルを管理する責任を負います。

ライフサイクル管理は、コンテンツの作成から最終的な提供終了までを処理するために使用するプロセスとプラクティスで構成されます。 ライフサイクル管理 の第 3 段階では、コンテンツの変更を検証します。これには、コンテンツ作成者とユーザーの両方によって実行された検証が含まれます。 第 4 段階では、コンシューマーがコンテンツを使用できるようにコンテンツを展開します。

Power BI コンテンツをコンシューマーと共有するには、まず、コンテンツを Fabric ワークスペースに発行 (または デプロイ) する必要があります。 また、コンテンツの展開には、開発ワークスペースからテスト ワークスペースへのデプロイや、テスト ワークスペースから運用ワークスペースへのデプロイなど、環境間でそのコンテンツを移動することも含まれます。

次の図は、Power BI コンテンツのライフサイクルを示しています。ステージ 4 では、コンテンツをデプロイします。

図は、Power BI コンテンツのライフサイクルを示しています。コンテンツの展開に関するステージ 4 が強調表示されています。

手記

コンテンツ ライフサイクル管理の概要については、このシリーズ の最初の記事参照してください。

この記事では、ライフサイクル全体を通じてコンテンツをデプロイするための主な考慮事項と決定事項に焦点を当てます。 コンテンツを展開する方法の詳細については、以下を参照してください。

コンテンツのライフサイクル中は、次の 2 つの主要なポイントでコンテンツを展開します。

  • 開発ワークスペースにコンテンツを発行する場合。 この時点で、コンテンツを発行して変更を検証します。
  • 2 つのワークスペース間でコンテンツを昇格する場合 (開発ワークスペースからテスト ワークスペースへのコンテンツの昇格など)。 この時点で、次のステージの準備ができたら (新しいコンテンツをテストする準備ができたら) コンテンツをデプロイします。

次のセクションでは、コンテンツの公開または昇格に使用できる方法について説明します。

コンテンツを公開する方法を決定する

ローカル コンピューターでコンテンツを開発する場合は、そのコンテンツを Fabric ポータルの開発ワークスペースに発行する必要があります。 通常、このコンテンツは、行った変更の検証実行する場合に発行します。

手記

この記事では、コンテンツの 発行を開発ワークスペースへの初期デプロイと説明します。 ただし、原則として、コンテンツの発行はデプロイと同じです。

Fabric ポータルで作成されたコンテンツ (データフロー、ダッシュボード、スコアカードなど) は開発ワークスペースに直接作成され、発行する必要はありません。

次のセクションでは、コンテンツを公開するために実行できるさまざまな方法について説明します。

Power BI Desktop を使用して発行する

Power BI Desktop を使用すると、ユーザーは、ローカル コンピューターから Fabric ポータルのワークスペースに セマンティック モデルとレポートを 発行できます。 この方法は、コンテンツを公開する最も簡単な方法です。ただし、自動化することはできません。

図は、Power BI Desktop からの発行に関するアプローチ 1 を示しています。次に、図の項目について説明します。

次の場合は、このアプローチを使用することを検討してください。

  • コンテンツ作成者は、Fabric ポータルへのコンテンツの発行を手動で制御することを好みます。
  • コンテンツ作成者は、Power BI Desktop を使用してコンテンツを開発および管理しています。
  • コンテンツ作成者は、Azure DevOps や Git に慣れていません。
  • コンテンツはセマンティック モデルまたはレポートのみで構成されます。

サード パーティ製ツールを使用して発行する

サード パーティ製ツールを使用すると、コンテンツ作成者は、XMLA 読み取り/書き込みエンドポイント ワークスペースを使用してセマンティック モデルを発行できます。 たとえば、コンテンツ作成者は、表形式エディターを使用して、TMDL (表形式モデル定義言語) や .bim ファイルなどのモデル メタデータを開発および管理します。

図は、サードパーティ製ツールからの発行に関するアプローチ 2 を示しています。次に、図の項目について説明します。

ヒント

サード パーティ製ツールを使用してセマンティック モデルをデプロイする方法の詳細については、高度なデータ モデル管理の使用シナリオを参照してください。

XMLA 読み取り/書き込みエンドポイントを有効にして使用する方法の詳細については、「セマンティック モデルと XMLA エンドポイントとの接続」を参照してください。

次の場合は、このアプローチを使用することを検討してください。

  • コンテンツ作成者は、Fabric ポータルへのコンテンツの発行を手動で制御することを好みます。
  • コンテンツ作成者は、サード パーティ製のツールを使用してコンテンツを開発および管理します。
  • コンテンツは、ユーザーごとの Premium (PPU)、Premium 容量、またはファブリック容量ライセンス モードを使用するワークスペースに発行されます。
  • コンテンツ作成者は、Azure DevOps や Git に慣れていません。
  • コンテンツはセマンティック モデルのみで構成されます。

OneDrive の更新を通じて公開する

OneDrive を使用すると、セルフサービス コンテンツ作成者は、OneDrive の更新を使用して、ファブリック ポータルのワークスペースにセマンティック モデルまたはレポートを自動的に発行できます。 コンテンツ作成者は、Power BI Desktop (.pbix) ファイルを OneDrive の共有ライブラリに保存できます。 共有ライブラリは、SharePoint または Microsoft Teams のドキュメントライブラリにすることもできます。

図は、OneDrive の更新を使用した発行に関する方法 3 を示しています。次に、図の項目について説明します。

ヒント

Power BI コンテンツで OneDrive for Work and School を使用する方法の詳細については、「セルフサービス コンテンツ発行の使用シナリオを参照してください。

OneDrive の更新を設定する方法の詳細については、「OneDrive または SharePoint Onlineに格納されているセマンティック モデルを更新する」を参照してください。

次の場合は、このアプローチを使用することを検討してください。

  • コンテンツ作成者は、Fabric ポータルへのコンテンツの発行を自動化したいと考えています。
  • コンテンツ作成者は、Azure DevOps や Git に慣れていません。
  • コンテンツ作成者は、OneDrive または SharePoint を使用してコンテンツのバージョン管理を実行します。
  • コンテンツ作成者は、セマンティック モデルとレポートを .pbix ファイルとして保存します。
  • コンテンツはセマンティック モデルまたはレポートのみで構成されます。

Fabric Git 統合を使用して発行する

Fabric Git 統合 は、コンテンツ作成者がリモート Git リポジトリから Fabric ワークスペースにブランチを同期できるようにする、Fabric 容量専用の機能です。 Git 統合を Azure DevOps と共に使用して Azure Repos のコンテンツを同期することも、Azure Pipelines を使用してコンテンツをデプロイすることもできます (次のセクションで説明します)。

手記

Azure DevOps は、コンテンツ ライフサイクル管理の計画と調整に役立つ、Power BI および Fabric と統合される一連のサービスです。 この方法で Azure DevOps を使用する場合、通常は次のサービスを利用します。

  • Azure Repos: リモート Git リポジトリを作成して使用できます。これは、コンテンツの変更を追跡および管理するために使用するリモート ストレージの場所です。
  • Azure Pipelines: リモート リポジトリからワークスペースへのコンテンツの処理、テスト、デプロイを行う一連の自動化されたタスクを作成して使用できます。
  • Azure Test Plans: ソリューションを検証し、Azure Pipelines と共に品質管理を自動化するテストを設計できます。
  • Azure Boards: ボードを使用してタスクと計画を作業項目として追跡したり、他の Azure DevOps サービスの作業項目をリンクまたは参照したりできます。
  • Azure Wiki: コンテンツを理解して投稿するための情報をチームと共有できます。

要約すると、コミットされてリモート リポジトリにプッシュされたコンテンツは、この同期プロセスを介してワークスペースに自動的に発行されます。 このアプローチの主な利点は、ソース管理 プロセスをコンテンツの公開と結合できる点です。 たとえば、ソリューションの変更やバージョン全体のロールバックが容易になります。

図は、Fabric Git 統合を使用した発行に関するアプローチ 4 を示しています。次に、図の項目について説明します。

ヒント

Fabric Git 統合を使用して Power BI コンテンツをデプロイする方法の詳細については、エンタープライズ コンテンツ発行の使用シナリオを参照してください。

Git 統合を設定する方法の詳細については、「チュートリアル: Fabric および Power BI Desktop プロジェクトのライフサイクル管理: Git 統合」を参照してください。

次の場合は、このアプローチを使用することを検討してください。

  • コンテンツ作成者は、Azure DevOps と Git に精通しています。
  • コンテンツ作成者は、コラボレーションとソース管理に Azure DevOps を使用しています。
  • コンテンツ作成者は、セマンティック モデルとレポートを Power BI プロジェクト (.pbip) ファイル 保存します。
  • コンテンツが Fabric 容量のワークスペースに公開される。
  • コンテンツは、Git 統合機能によって サポートされている項目の種類で構成されます。
  • コンテンツに秘密度ラベルが含まれていない。

手記

Git 統合を使用してコンテンツをデプロイおよび管理する方法は、ライフサイクル管理のステージ 2 で決定する の分岐とマージの戦略に大きく依存します。

Azure Pipelines を使用して発行する

Azure Pipelines プログラムによって、コンテンツのテスト、管理、デプロイを自動化します。 パイプラインが実行されると、パイプライン内のステップが自動的に実行されます。 Azure Pipelines は複雑で、他のアプローチと比較してセットアップに多くの時間と労力が必要ですが、デプロイ プロセスを調整するための制御と柔軟性が最も高くなります。

図は、Azure DevOps で Azure Pipelines を使用した発行に関するアプローチ 5 を示しています。次に、図の項目について説明します。

ヒント

Azure Pipelines と Power BI REST API を使用して、Fabric または Premium 容量にないワークスペースにコンテンツをデプロイできます。 ただし、Fabric REST API は Fabric でのみ機能し、XMLA エンドポイントは Fabric または Premium 容量でのみ機能します。

Azure Pipelines を使用して Power BI コンテンツをデプロイする方法の詳細については、エンタープライズ コンテンツ発行の使用シナリオを参照してください。

Azure DevOps と Power BI を統合する方法の詳細については、Power BI Desktop プロジェクトの Azure DevOps 統合 とビルド パイプライン に関するページを参照してください。

次の場合は、Azure Pipelines を使用してコンテンツのデプロイを調整することを検討してください。

  • コンテンツ作成者は、Azure DevOps と Fabric REST API に精通しています。
  • コンテンツ作成者は、コラボレーションとソース管理に Azure DevOps を使用しています。
  • コンテンツ作成者は、Fabric Git 統合を使用していません。

Azure Pipelines やその他のコード ベースのツールでは、次の 1 つ以上の API またはエンドポイントを使用して、プログラムによってコンテンツをデプロイできます。

  • Power BI REST API: コンテンツのデプロイに使用できるさまざまな Power BI REST API エンドポイントがあります。 Power BI REST API では、Power BI 項目の種類のみがサポートされます。
    • インポート: Power BI REST API を使用して、有効なソース ファイル (.pbix ファイルなど) をワークスペースにインポートすることで、サポートされている項目を発行できます。
    • のデプロイ: サポートされている項目をデプロイし、展開パイプラインのステージである場合は、それらをワークスペース間で昇格させることができます。
  • Fabric REST API: コンテンツのデプロイに使用できるさまざまな Fabric REST API エンドポイントがあります。 Fabric REST API では、Power BI と Fabric の両方の項目の種類がサポートされます。
    • の作成: Fabric REST API と有効な 項目定義を使用して、サポートされている項目を作成できます。
    • Gitからの更新: Git 統合を使用して、リモート リポジトリのコンテンツを使用してワークスペースを更新できます。
  • XMLA 読み取り/書き込みエンドポイント: 有効な model.bim ファイルと共に XMLA エンドポイントを使用して、の作成や セマンティック モデルの の変更をできます。 XMLA エンドポイントを使用すると、モデル全体ではなく、特定のモデル オブジェクトに変更をデプロイできます。 Azure Pipelines では、XMLA エンドポイントを使用して、サードパーティ製のツール (表形式エディターのコマンド ライン インターフェイスなど) を使用してセマンティック モデルをデプロイできます。

ヒント

Fabric または Power BI REST API を使用する場合は、まず Azure でアプリ登録を作成する必要があります (Power BI Embeddedについては、ここで説明します)。 これには Microsoft Entra ID テナントと組織ユーザーが必要であり、適切なアクセス許可を設定するための複雑なプロセスになる可能性があります。 ただし、アプリの登録を作成しなくても、ノートブックで Fabric REST API を実行できます。 これにより、ソリューションでの API のセットアップと使用が効率化されるため、API を使用する前に資格情報を管理したり、セットアップを構成したりする必要がなくなります。

アプリを登録せずにFabric REST APIを使用するには、FabricノートブックでsempyのFabricRestClientClassを使用し、セマンティックリンクを通じてAPIを呼び出します。

Azure Pipelines と Power BI の統合は、自動テストと共に、継続的インテグレーションと継続的デプロイ (CI/CD) 実現するのに役立ちます。

Azure Pipelines を使用する場合、パイプライン所有者は、デプロイのニーズに合わせてトリガー、手順、機能をカスタマイズできます。 そのため、パイプラインの数と種類は、ソリューションの要件によって異なります。

Power BI ソリューションをテスト、管理、デプロイするように設定できる Azure Pipelines には、3 種類あります。

  • 検証パイプライン
  • パイプラインをビルドする
  • リリース パイプライン

手記

発行ソリューションに 3 種類のパイプラインをすべて含める必要はありません。 ワークフローとニーズに応じて、コンテンツの公開を自動化するために、この記事で説明するパイプラインのバリエーションを 1 つ以上設定できます。 パイプラインをカスタマイズするこの機能は、組み込みの Fabric デプロイ パイプラインよりも Azure Pipelines の利点です。

検証パイプライン

検証パイプラインは、開発ワークスペースに公開される前に、データ モデルの基本的な品質チェックを実行します。 通常、リモートリポジトリのブランチでの変更はパイプラインをトリガーし、その変更を 自動化テストによって検証します。

自動テストの例としては、ベスト プラクティス アナライザー (BPA)を使用するか、パブリッシュされたセマンティック モデルに対して DAX クエリを実行して、データ モデルをスキャンしてベスト プラクティスルール違反を検出する方法があります。 これらのテストの結果は、ドキュメントと監査の目的でリモート リポジトリに格納されます。 検証に失敗したデータ モデルは公開しないでください。 代わりに、パイプラインはコンテンツ作成者に問題を通知する必要があります。

パイプラインをビルドする

Power BI サービスに公開するためにデータ モデルを準備 パイプラインを構築します。 これらのパイプラインは、シリアル化されたモデル メタデータを、リリース パイプラインによって後で発行される 1 つのファイルに結合します。 ビルド パイプラインでは、パラメーター値の変更など、メタデータを変更することもできます。 ビルド パイプラインは、Power BI サービスに公開する準備ができているデータ モデル メタデータ (データ モデルの場合) と Power BI プロジェクト (.pbip) ファイルで構成されるデプロイ 成果物を生成します。

リリース パイプライン

リリース パイプラインでは、コンテンツを発行またはデプロイします。 発行ソリューションには、通常、ターゲット環境に応じて、いくつかのリリース パイプラインが含まれます。

  • 開発リリース パイプライン: この最初のパイプラインは自動的にトリガーされます。 ビルドパイプラインと検証パイプラインが成功した後、開発ワークスペースにコンテンツを発行します。
  • テスト および実稼働リリース パイプライン: これらのパイプラインは自動的にはトリガーされません。 代わりに、要求時または承認時にトリガーされます。 テストリリースパイプラインと実稼働リリースパイプラインでは、リリース承認 の後に、それぞれのコンテンツをテストワークスペースまたは運用ワークスペースにデプロイします。 リリースの承認 準備が整う前に、コンテンツがテストまたは実稼働ステージに自動的に展開されないようにします。 これらの承認は、テスト環境と運用環境へのコンテンツ リリースの計画と調整を担当するリリース マネージャーによって提供されます。

ワークスペース間でコンテンツを共有する方法を決定する

開発、テスト、運用に異なる環境を使用する場合は、3 つの環境すべてにコンテンツを展開する必要があります。 特定のワークフローとニーズに応じて、ワークスペース間でコンテンツを昇格させるために使用できるさまざまなツールとアプローチがあります。

次のセクションでは、ワークスペースの間でコンテンツを促進するために使える方法について説明します。

注意

ローカル コンピューターからテストおよび運用ワークスペースにコンテンツを手動で公開するのは避けてください。 誤りによりエラーや中断が発生する可能性があります。 一般に、開発ワークスペースにのみ発行するか、プライベート ワークスペースを使用する場合は に発行する必要があります。

Fabric 展開パイプラインを使用して展開する

デプロイ パイプラインを使用すると、2 つ以上のステージ (開発、テスト、運用など) を設定し、これらのステージ間に Fabric コンテンツをデプロイできます。 パイプライン管理者は、デプロイ パイプラインの各ステージに 1 つの Power BI ワークスペースを割り当てます。 ワークスペースをどのように 設定し使用するかを決定したかによって、デプロイパイプラインの使用方法が異なります。

次の場合は、デプロイ パイプラインの使用を検討してください。

  • コンテンツは、PPU、Premium 容量、またはファブリック容量ライセンス モードのワークスペースにデプロイされます。
  • コンテンツ 項目の種類とシナリオは、デプロイ パイプラインでサポートされています。

次の場合は、デプロイ パイプライン以外の方法を検討してください。

  • Azure Pipelines を使用するなどして、リモート リポジトリからコンテンツをデプロイすることをお勧めします。
  • Git 統合を使用して、コンテンツをデプロイするのではなく、異なるステージをリモート リポジトリのさまざまなブランチと同期する予定です。

ヒント

デプロイ パイプラインを使用してワークスペース間でコンテンツを昇格する方法の詳細については、セルフサービス コンテンツ発行 とエンタープライズ コンテンツ発行 使用シナリオ を参照してください。

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

デプロイ パイプラインを使用する最も簡単な方法は、すべてのコンテンツを 1 つのワークスペースに発行し、1 つのデプロイ パイプライン内の後のステージに昇格させる場合です。 次の図は、デプロイ パイプラインを使用してコンテンツをデプロイするこの最初のアプローチを示しています。

図は、デプロイ パイプラインを使用したコンテンツのデプロイに関するアプローチ 1 を示しています。次に、図の項目について説明します。

要約すると、コンテンツ作成者は通常、最初にパイプラインの初期段階にコンテンツを発行します。 次に、コンテンツを後のステージに昇格させるために、パイプライン管理者がデプロイをトリガーします。 デプロイが発生すると、デプロイ パイプラインは、あるワークスペースから次のワークスペースにコンテンツ メタデータをデプロイします。

異なるワークスペースで項目の種類ごとにコンテンツを分離する場合は、個別のデプロイ パイプラインを使用してこのコンテンツをデプロイします。 自動バインドを使用すると、複数の展開パイプラインでワークスペースにまたがってコンテンツをリンクできます。 デプロイ パイプライン間での自動バインドにより、コンテンツがそれぞれのステージの適切な項目にリンクされたままになります。 たとえば、開発ステージのレポートは、他のデプロイ パイプラインの開発ステージのモデルにリンクされたままになります。 ただし、あるシナリオで別のパターンのワークスペースにまたがってコンテンツをリンクする必要がある場合は、自動バインドの動作を回避することもできます。

次の図は、複数のデプロイ パイプラインを使用してコンテンツをデプロイするこの 2 番目の方法を示しています。

図は、複数のパイプラインを使用したコンテンツのデプロイに関するアプローチ 2 を示しています。次に、図の項目について説明します。

要約すると、複数のデプロイ パイプラインを使用してコンテンツをデプロイすることは、1 つのパイプラインを使用するのと似ています。 主な違いは、必要に応じて、自動バインドを使用して、ワークスペースとデプロイ パイプライン間で接続されているコンテンツをリンクできることです。 それ以外の場合は、最初のアプローチと同じです。

デプロイ パイプラインは、セルフサービス シナリオとエンタープライズ シナリオの両方でコンテンツ ライフサイクル管理を改善するのに適した、柔軟で簡単なツールです。

デプロイを実行するユーザーには、ワークスペースとデプロイ パイプラインの両方 へのアクセスが必要です。 パイプライン管理者がデプロイ履歴を表示してコンテンツを比較できるように、デプロイ パイプラインアクセス を計画 することをお勧めします。 複数のコンテンツ作成者と共同作業する場合は、デプロイとリリースのプロセスを監督するのに最適なリリース マネージャーまたは技術所有者へのパイプライン アクセスを制限することを検討してください。

さらに、展開規則 を使用して、異なるステージの項目に対して異なる構成を設定することを検討してください。 たとえば、開発ワークスペース内のセマンティック モデルで開発データベースからデータをソースする一方で、運用ワークスペースのセマンティック モデルは運用データベースからデータをソースする場合があります。

ヒント

複数のユーザーがデプロイ パイプラインにアクセスできる場合は、デプロイ履歴 定期的に確認することをお勧めします。 これらのレビューは、未承認のデプロイまたはデプロイの失敗を特定するのに役立ちます。

自動バインド を使用してデプロイ パイプライン間で項目をリンクしている場合は、リンクされたコンテンツを間違ったステージに公開したユーザーが原因で発生する自動バインドの中断を特定するために、アイテムの系列も確認してください。

Power BI REST APIを使用して、手動またはプログラムでデプロイをトリガーできます。 どちらの場合も、コンテンツを各ステージに昇格させるタイミングと、意図しない変更をロールバックする方法について、明確で堅牢なプロセスを定義する必要があります。

デプロイを手動で実行する

Fabric デプロイ パイプラインを使用して、コンテンツを手動でデプロイできます。 すべてのコンテンツを展開するか、または項目を選択するかを選択できます。 一部のコンテンツが次のステージに進む準備ができているが、一部の項目がまだ開発または検証中である場合は、選択的デプロイが役立ちます。 さらに、コンテンツの変更が後のステージに存在するが、以前のステージには存在しない場合は、の後方展開 を実行できます。

注意

デプロイ パイプラインを使用する場合は、開発からテスト、運用ワークスペースなど、単一の方向にコンテンツをデプロイすることをお勧めします。 通常、これらの変更が開発またはテストで適切な検証を行う前に、後の段階でコンテンツに変更を加えないようにする必要があります。

手動の展開を実行する場合は、[変更内容の確認] ウィンドウでステージを比較して、コンテンツ変更を識別できます。 この方法は、ソース管理に Git リモート リポジトリを使用しない場合に特に便利です。

Power BI REST API を使用してデプロイを実行する

Power BI REST API を使用して、デプロイ パイプライン を使用してコンテンツをデプロイできます。 REST API を使用する利点は、デプロイを自動化し、Azure DevOps の Azure Pipelines などの他のツールと統合できることです。

Azure Pipelines を使用したデプロイ

Azure Pipelines を使用すると、すべてのステージ間でデプロイを調整できます。 この方法では、Fabric REST API を使用してコンテンツをデプロイおよび管理し、検証パイプラインやリリース パイプラインなどのさまざまな Azure Pipelines を使用します。

次の場合は、Azure Pipelines の使用を検討してください。

  • Azure DevOps 内からデプロイのオーケストレーションを一元化する必要があります。
  • コンテンツ作成者は、Azure DevOps を使用して共同作業を行い、ソース管理を行っています。

次の場合は、Azure Pipelines 以外のアプローチを検討してください。

  • コンテンツ作成者は、Azure DevOps やコードベースのデプロイに慣れていません。
  • コンテンツには、ダッシュボードなど、サポートされている定義やソース ファイル形式を持たないアイテムの種類が含まれます。

Azure Pipelines を使用してコンテンツをデプロイするには、2 つの異なる方法があります。 デプロイ パイプラインを調整するか、デプロイ パイプラインなしでワークスペースにコンテンツをデプロイします。

Azure Pipelines を使用して Fabric デプロイ パイプラインを調整する

このアプローチでは、リリース パイプラインは、デプロイ パイプラインを使用してコンテンツのデプロイを調整し、テストワークスペースと運用ワークスペースを調整します。 コンテンツは、Fabric の開発、テスト、本番環境のワークスペースを通じてプロモートされます。

次の図は、Azure Pipelines からデプロイ パイプラインを調整する方法を示しています。

図は、Azure Pipelines からのコンテンツ デプロイの調整に関するアプローチ 3 を示しています。次に、図の項目について説明します。

要約すると、コンテンツ作成者は、デプロイ パイプラインの最初のステージでワークスペースにコンテンツを発行します。 その後、リリース マネージャーによってデプロイが承認され、Azure Pipeline がトリガーされます。 このパイプラインでは、Power BI REST API を使用してステージ間でコンテンツを昇格し、メタデータが別のワークスペースにデプロイされるようにします。 この方法の利点の 1 つは、デプロイ パイプラインを使用して複数の Fabric 項目の種類のデプロイを調整できることです。一部の項目の種類は Fabric ポータルで開発されているため、Azure Pipelines だけではデプロイできないためです。

Azure Pipelines のみを使用してコンテンツをデプロイする

Azure Pipelines を使用して、Azure DevOps からワークスペースにコンテンツをデプロイすることもできます。 この方法では、デプロイ パイプラインは使用されません。 代わりに、リリース パイプラインを使用して、Fabric または Power BI REST API または XMLA 読み取り/書き込みエンドポイントを使用してソース ファイルまたはメタデータ ファイルをデプロイします。 通常、これらのファイルは Azure Repos Git リポジトリに格納されます。

次の図は、Azure Pipelines のみを使用してコンテンツをデプロイする方法を示しています。

図は、Azure Pipelines のみを使用したコンテンツのデプロイに関するアプローチ 4 を示しています。次に、図の項目について説明します。

要約すると、コンテンツ作成者は、コンテンツの変更をコミットし、Azure Repos のリモート Git リポジトリにプッシュします。 このコンテンツは、デプロイのために Azure Pipelines によって使用されます。 リリース マネージャーが特定のデプロイを承認すると、Azure Pipeline は、Power BI REST API (.pbix ファイルの場合)、Fabric REST API (つまり、項目定義用)、または XMLA エンドポイント (つまり model.bim ファイル用) を使用して、ワークスペースにコンテンツをデプロイします。 ワークスペースごとに個別の Azure Pipeline が存在します。

Power BI REST API を使用して Power BI Desktop ファイルのみを発行する場合、この方法では Fabric 容量や Premium ライセンスは必要ありません。 ただし、Power BI の外部でデプロイを管理する必要があるため、セットアップ作業と複雑さが増します。 Power BI 以外のデータ ソリューションに DevOps を既に使用している開発チームは、このアプローチに精通している可能性があります。 このアプローチを使用する開発チームは、Azure DevOps でのデータ ソリューションのデプロイを統合できます。

Fabric Git 統合を使用したデプロイ

Git 統合を使用すると、コンテンツを明示的に発行またはデプロイする代わりに、異なるブランチを異なるワークスペースに同期できます。 そうすることで、開発、テスト、運用の各ワークスペースに個別のブランチを作成できます。 このシナリオでは、メイン ブランチは、運用 ワークスペースと同期されます。 次に、プル要求を実行して、開発ブランチをテスト ブランチにマージするか (テスト ワークスペースにデプロイするため)、またはテスト ブランチをメイン ブランチにマージして (運用ワークスペースにデプロイするために)、ワークスペース間でコンテンツをデプロイします。

次の図は、Fabric Git 統合を使用してブランチを異なるワークスペースに同期することでコンテンツをデプロイする方法を示しています。 わかりやすくするために、図にはコンテンツの分岐またはマージの詳細は含まれません。

図は、Fabric Git 統合を使用したコンテンツのデプロイに関するアプローチ 5 を示しています。次に、図の項目について説明します。

要約すると、コンテンツ作成者は、コンテンツの変更をコミットし、Azure Repos のリモート Git リポジトリにプッシュします。 コンテンツ作成者は、プル要求 (PR) を開いて、変更を特定のブランチにマージするよう要求します。 ブランチ戦略に応じて、異なるブランチが異なるワークスペースに接続されます。 変更がブランチにマージされると、コンテンツ作成者はワークスペースをリモート Git リポジトリと同期して、そのワークスペース内のコンテンツに対する最新の変更を表示します。

次の場合は、このアプローチを検討してください。

  • ブランチ戦略とマージ戦略を使用して、ワークスペース間のデプロイを調整する必要があります。
  • Azure Pipelines または Fabric デプロイ パイプラインを使用して、デプロイを調整してテストと運用を行う予定はありません。
  • ワークスペースには、サポートされていない項目 または シナリオ含まれません。
  • コンテンツに秘密度ラベルが含まれていない。

手記

コンテンツを展開する有効な方法は多数あります。 たとえば、この記事で説明するさまざまな方法を組み合わせて使用できます。

たとえば、Azure Pipeline を使用して開発ワークスペースにコンテンツをデプロイできます。これにより、継続的インテグレーション機能の恩恵を受け、自動テスト (ベスト プラクティス アナライザーの使用など) を行うことができます。 その後、Git 統合または Fabric デプロイ パイプラインを使用して、ワークスペース間でコンテンツをデプロイできます。

ニーズとチームの働き方に最適なアプローチを選択します。

デプロイ後のアクティビティを処理する方法を決定する

デプロイ後、処理する必要があるさまざまな 展開後アクティビティ があります。 これらのアクティビティの多くは、たとえば Azure Pipeline または Notebook、Power BI および Fabric REST API によってプログラムで処理できます。 たとえば、プログラムでデータ ソースの資格情報を設定したり、スケジュールされた更新を管理したり、メタデータのデプロイ後に更新をトリガーすることができます。 ただし、一部のタスクでは、初回セットアップや Power BI アプリの更新など、手動による介入が必要です。

コンテンツに関連するすべての展開後アクティビティを特定し、それらの処理方法を決定します。

コンテンツの展開方法を計画したら、次にコンテンツのサポートを し、 監視する方法を検討する必要があります。

チェックリスト - コンテンツの展開方法を計画する場合、主な決定事項とアクションは次のとおりです。

  • で使用可能な展開オプションを特定する: ライセンスとコンテンツに応じて、コンテンツを公開したり、ワークスペース間で昇格したりするためのさまざまなオプションを使用できます。 デプロイ パイプライン、Azure DevOps、Git 統合、Fabric REST API、XMLA 読み取り/書き込みエンドポイントを使用できるかどうかを特定します。
  • コンテンツを公開する方法を決定する: ワークフローとニーズに最も適したコンテンツを公開する方法を選択します。 変更を追跡および管理する方法など、このアプローチが他の戦略と一致していることを確認します。
  • ワークスペース間でコンテンツを昇格させる方法を決定: 開発ワークスペースからテストワークスペースへ、そしてテストワークスペースから本番ワークスペースへコンテンツを展開する手法を選択します。 このアプローチは、コンテンツを公開する方法など、他の戦略と一致していることを確認します。
  • リリース戦略を計画する: リリースまたは展開を承認する前に、特定の個人がコンテンツの最終レビューを担当するかどうかを決定します。 この個人がこのタスクを認識しており、デプロイ プロセスを保護するために何をすべきかを把握していることを確認し、進行を妨げることのないようにします。
  • デプロイ後のアクティビティを計画する: メタデータのデプロイ後に Power BI アプリの更新やデータ項目の更新などのアクティビティを実行するプロセスを決定していることを確認します。 Fabric REST API を使用して、このプロセスを自動化することを検討してください。
  • 展開ツールとプロセスの初回セットアップを実行する: 適切なアクセスを設定し、そのアクセス許可がコンテンツへのアクセスを設定する方法と一致していることを確認します。
  • 運用環境のにコンテンツを展開する: デプロイを計画して設定したら、コンテンツを運用環境に展開します。

関連コンテンツ

このシリーズ の次の記事では、コンテンツ ライフサイクルの管理の一環としてコンテンツをサポートおよび監視する方法について説明します。