次の方法で共有

Power BI 実装計画: コンテンツを展開する

  • [アーティクル]

Note

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

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

  • Fabric 管理者: 組織の 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 ステージが強調表示されています。

Note

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

この記事は、コンテンツをそのライフサイクルを通して展開するための主な考慮事項と意思決定に重点を置いています。 コンテンツを展開する方法に関するその他のガイダンスについては、次を参照してください。

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

  • コンテンツを開発ワークスペースに公開するとき。 この時点では、変更内容を検証するためにコンテンツを公開します。
  • コンテンツを 2 つのワークスペース間で昇格させるとき (開発ワークスペースからテスト ワークスペースへのコンテンツの昇格など)。 この時点では、次のステージに移行する準備ができたときにコンテンツを展開します (新しいコンテンツをテストする準備ができた場合など)。

以降のセクションでは、コンテンツを公開するか、または昇格させるために使用できるアプローチの概要について説明します。

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

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

Note

この記事で、コンテンツの "公開" とは開発ワークスペースへの初期の展開のことを指します。 ただし、原則として、コンテンツの公開はその展開と同じです。

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

以降のセクションでは、コンテンツを公開するために使用できるさまざまなアプローチについて説明します。

Power BI Desktop を使用して公開する

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

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

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

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

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

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

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

ヒント

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

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

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

  • コンテンツ作成者が Fabric ポータルへのコンテンツの公開を手動で制御したい。
  • コンテンツ作成者がサード パーティ製ツールを使用してコンテンツを開発および管理している。
  • コンテンツが、Premium Per User (PPU)、Premium 容量、または Fabric 容量ライセンス モードを使用するワークスペースに公開される。
  • コンテンツ作成者が Azure DevOps や Git に精通していない。
  • コンテンツがセマンティック モデルのみで構成されている。

OneDrive の更新を使用して公開する

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

図は、OneDrive の更新を使用した公開に関するアプローチ 3 を示しています。図の項目については、次に説明されています。

ヒント

Power BI コンテンツで職場または学校向け OneDrive を使用する方法の詳細については、セルフサービス コンテンツの公開の使用シナリオに関するページを参照してください。

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 (次のセクションで説明します) を使用してコンテンツを展開したりできます。

Note

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 統合機能によってサポートされている項目の種類で構成されている。
  • コンテンツに秘密度ラベルが含まれていない。

Note

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 などのコード ベースのツールでは、次の API またはエンドポイントの 1 つ以上を使用して、プログラムでコンテンツを展開できます。

  • 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 読み取り/書き込みエンドポイント: XMLA エンドポイントを有効な model.bim ファイルと共に使用して、セマンティック モデルを "作成" または "変更" できます。 XMLA エンドポイントを使用すると、変更をモデル全体にではなく、特定のモデル オブジェクトに展開できます。 Azure Pipelines では、サード パーティ製ツール (Tabular Editor コマンド ライン インターフェイスなど) を使用して、XMLA エンドポイントを使用してセマンティック モデルを展開できます。

ヒント

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

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

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

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

Power BI ソリューションをテスト、管理、展開するために設定できる Azure Pipelines には、次の 3 種類があります。

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

Note

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

検証パイプライン

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

自動テストの例としては、Best Practice Analyzer (BPA) を使ってデータ モデルをスキャンしてベスト プラクティス規則に違反していないか確認する場合や、公開されたセマンティック モデルに対して DAX クエリを実行する場合などがあります。 このようなテストの結果は、文書化と監査のためにリモート リポジトリに格納されます。 検証に失敗したデータ モデルは公開しないでください。 代わりに、パイプラインからコンテンツ作成者に問題を通知するようにします。

ビルド パイプライン

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

リリース パイプライン

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

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

コンテンツをワークスペース間で昇格させる方法を決定する

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

以降のセクションでは、コンテンツをワークスペース間で昇格させるために使用できるアプローチについて説明します。

注意事項

コンテンツをローカル マシンからテストおよび運用ワークスペースに手動で公開することは避けてください。 それにより、間違いによるエラーや中断が発生する場合があります。 一般に、公開する先は開発ワークスペースか、またはプライベート ワークスペース (使用している場合) だけにする必要があります。

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

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

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

  • コンテンツが、PPU、Premium 容量、または Fabric 容量ライセンス モードのワークスペースに展開される。
  • コンテンツ項目の種類とシナリオが展開パイプラインでサポートされている。

次の場合は、展開パイプラインとは別のアプローチを検討してください。

  • リモート リポジトリから (Azure Pipelines などを使用して) コンテンツを展開したい。
  • コンテンツを展開するのではなく、Git 統合を使用して、異なるステージをリモート リポジトリの異なるブランチと同期することを予定している。

ヒント

展開パイプラインを使用してコンテンツをワークスペース間で昇格させる方法の詳細については、セルフサービス コンテンツの公開およびエンタープライズ コンテンツの公開の使用シナリオを参照してください。

展開パイプラインの詳細については、展開パイプライン: 展開プロセスの概要に関するページを参照してください。

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

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

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

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

次の図は、複数の展開パイプラインを使用してコンテンツを展開するためのこの 2 番目のアプローチを示しています。

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

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

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

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

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

ヒント

複数のユーザーが展開パイプラインにアクセスできる場合は、展開履歴を定期的に確認することをお勧めします。 これらの確認は、承認されていない展開や展開エラーを識別するのに役立ちます。

自動バインドを使用して展開パイプラインにまたがって項目をリンクしている場合は、リンクされたコンテンツをだれかが間違ったステージに公開したために発生する自動バインドの中断を識別するために、必ず項目の系列も確認するようにしてください。

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

展開を手動で実行する

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

注意事項

展開パイプラインを使用している場合は、コンテンツを 1 方向に (開発ワークスペースからテスト ワークスペース、運用ワークスペースへなど) 展開することをお勧めします。 通常、変更が開発またはテストでの適切な検証を経る前に、後のステージでそれらの変更をコンテンツに加えることは避ける必要があります。

手動の展開を実行する場合は、[変更内容の確認] ウィンドウでステージを比較して、コンテンツ変更を識別できます。 このアプローチは、ソース管理に 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 を示しています。図の項目については、次に説明されています。

要約すると、コンテンツ作成者は、展開パイプラインの第 1 ステージでコンテンツをワークスペースに公開します。 次に、リリース マネージャーがその展開を承認し、それにより 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 統合を使用する場合は、コンテンツを明示的に公開または展開するのではなく、異なるブランチを異なるワークスペースと同期できます。 それにより、開発、テスト、運用の各ワークスペースに個別のブランチを使用できます。 このシナリオでは、"メイン" ブランチは "運用" ワークスペースと同期します。 その後、pull request を実行して、開発ブランチを (テスト ワークスペースに展開するために) テスト ブランチにマージするか、またはテスト ブランチを (運用ワークスペースに展開するために) メイン ブランチにマージすることによって、コンテンツをワークスペース間で展開します。

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

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

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

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

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

Note

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

たとえば、Azure Pipeline を使用してコンテンツを開発ワークスペースに展開できます。これにより、継続的インテグレーション機能の利点を生かし、自動テスト (ベスト プラクティス アナライザーの使用など) を実行できます。 次に、Git 統合または Fabric 展開パイプラインのどちらかを使用して、コンテンツをワークスペース間で展開できます。

ニーズやチームの作業方法に最適なアプローチを選択してください。

展開後アクティビティを処理する方法を決定する

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

必ずコンテンツに関連するすべての展開後アクティビティを識別し、それらが処理される方法を決定するようにしてください。

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

チェックリスト - コンテンツを展開する方法を計画する場合、主要な意思決定とアクションには次のものが含まれます。

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

関連するコンテンツ

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