Power BI の使用シナリオ: エンタープライズコンテンツの公開

[アーティクル]
12/13/2023

注意

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

複数のコンテンツ作成者が協力し、組織にとって重要な分析ソリューションを提供する場合、コンシューマーにコンテンツをタイムリーかつ確実に配信する必要があります。技術チームは DevOps というプロセスを使ってこの課題に取り組んでいます。 DevOps を使うと、チームは配信を改善し、迅速にするプラクティスを採用することで、プロセスを自動化し、スケーリングできます。

Note

同じ課題に取り組むデータチームも DataOps を実行することがあります。 DataOps は DevOps の原則に基づいていますが、DataOps には、データ品質保証やガバナンスなど、データ管理に固有のプラクティスが追加されています。この記事では DevOps に言及していますが、基本的な原則は DataOps にも適用できることに留意してください。

Power BI コンテンツの公開に DevOps のプラクティスを採用すると、コンテンツ作成者とコンシューマーにはいくつかのベネフィットがあります。このプロセスのしくみについて概要を次に示します。

コンテンツを開発し、リモートリポジトリに作業をコミットする: コンテンツ作成者は自分のマシン上でソリューションを開発します。開発中は定期的に作業内容を "リモートリポジトリ" にコミットして保存します。リモートリポジトリにはソリューションの最新バージョンが格納されており、開発チームの全員がアクセスできます。
バージョン管理を使ってコンテンツの変更を共同で管理する: 他のコンテンツ作成者は "ブランチ" を作成することでソリューションに修正を加えることができます。ブランチはリモートリポジトリのコピーです。このようなリビジョンの準備が整い、承認されると、そのブランチはソリューションの最新バージョンとマージされます。ソリューションに対するすべてのリビジョンは追跡されます。このプロセスは "バージョン管理" (または "ソース管理") と呼ばれます。
パイプラインを使ったコンテンツのデプロイと昇格:セルフサービスコンテンツ公開の使用シナリオでは、Power BI デプロイパイプラインを使ってコンテンツを開発、テスト、運用環境ワークスペースに昇格 (または "デプロイ") することができます。 Power BI デプロイパイプラインでは、ユーザーインターフェイスを使って手動で、または REST API を使ってプログラムでコンテンツを Power BI Premium ワークスペースに昇格することができます。一方、エンタープライズコンテンツ公開 (この使用シナリオの焦点) の場合、Azure Pipelines を使ってコンテンツを昇格します。 Azure Pipelines は、カスタマイズされた一連のプログラムによる手順を使ってコンテンツのテスト、管理、デプロイを自動化する Azure DevOps サービスです。エンタープライズコンテンツ公開の使用シナリオでは、このようなパイプラインは "継続的インテグレーションとデプロイ" (つまり CI/CD) パイプラインとも呼ばれます。これらのパイプラインは、頻繁かつ自動的に変更を統合し、コンテンツ公開を効率化します。

重要

この記事では、Power BI Premium またはその容量サブスクリプション (P SKU) に言及することがあります。現在、Microsoft は購入オプションを統合し、容量あたりの Power BI Premium SKU を廃止していることに注意してください。新規および既存のお客様は、代わりに Fabric 容量サブスクリプション (F SKU) の購入をご検討ください。

詳細については、「Power BI Premium ライセンスに関する重要な更新」と「Power BI Premium のよく寄せられる質問」を参照してください。

DevOps は、コンテンツの管理と公開に対する成熟した体系的なアプローチをサポートします。そのため、複数のコンテンツ作成者がソリューションについて共同作業できます。また、コンテンツをコンシューマーに迅速かつ確実に配信できます。 DevOps のプラクティスを順守することで、ワークフローの効率化、エラーの減少、コンテンツ作成者とコンテンツコンシューマーのエクスペリエンスの向上というベネフィットがあります。

Power BI ソリューションの DevOps プラクティスの設定と管理には Azure DevOps を使います。エンタープライズシナリオでは、Azure DevOps と Power BI REST API を使い、3 種類の方法でコンテンツの公開を自動化できます。

Power BI REST API と Power BI デプロイパイプライン: 開発ワークスペースにコンテンツをインポートし、デプロイパイプラインを使い、テストと運用環境のワークスペースを介してコンテンツをデプロイできます。デプロイの管理は引き続き Azure DevOps から行います。また、Power BI REST API を使って、個々のコンテンツ項目ではなくデプロイパイプラインを管理します。さらに、Azure DevOps で XMLA エンドポイントを使って、Power BI Desktop ファイル (.pbix) ではなくデータモデルメタデータをデプロイします。このメタデータにより、バージョン管理を使ってオブジェクトレベルの変更を追跡できます。このアプローチは、より堅牢で保守が簡単ですが、Premium ライセンスと、Power BI REST API を使ってコンテンツのインポートとデプロイを設定するために中程度のスクリプト作成作業が必要です。デプロイパイプラインを使ってコンテンツのライフサイクル管理を簡略化したいと考えていて、Premium ライセンスを持っている場合は、このアプローチを使います。 XMLA エンドポイントと Power BI デプロイパイプラインは Premium 機能です。
Power BI REST API: Azure DevOps と Power BI REST API のみを使って、開発、テスト、運用環境のワークスペースにコンテンツをインポートすることもできます。このアプローチに Premium ライセンスは必要ありませんが、デプロイは Power BI の外部で管理されるため、スクリプトの作成と設定に多大な労力がかかります。 Power BI コンテンツを Azure DevOps から一元的にデプロイする場合や、Premium ライセンスを持っていない場合は、このアプローチを使います。最初の 2 つのアプローチの視覚的な比較については、リリースパイプラインアプローチのフロー図を参照してください。
Power BI オートメーションツールと Power BI デプロイパイプライン: Power BI REST API ではなく Power BI オートメーションツール Azure DevOps 拡張機能を使ってデプロイパイプラインを管理できます。このアプローチは、Power BI デプロイパイプラインで Power BI REST API を使うという 1 つ目のオプションに代わるものです。 Power BI オートメーションツール拡張機能はオープンソースツールです。 PowerShell スクリプトを作成しなくても、Azure DevOps からコンテンツの管理と公開を行うことができます。スクリプトの作成作業を最小限に抑えて Azure DevOps からデプロイパイプラインを管理したいと考えていて、Premium 容量がある場合にこのアプローチを使います。

この記事では、Power BI デプロイパイプラインで Power BI REST API を使うという 1 つ目のオプションに焦点を当てます。 Azure DevOps を使って DevOps プラクティスを設定する方法について説明します。また、リモートリポジトリに Azure Repos を使い、Azure Pipelines を使ってコンテンツのテスト、統合、配信を自動化する方法についても説明します。 Azure DevOps は、エンタープライズコンテンツ公開を設定する唯一の方法ではありませんが、Power BI との統合が簡単なので、お勧めの選択肢です。

注意

この使用シナリオは、コンテンツ管理とデプロイシナリオの 1 つです。簡潔にするために、コンテンツのコラボレーションと配信のシナリオに関するトピックで説明されている一部の側面については、この記事から除外されています。全体については、先にこれらの記事を参照してください。

ヒント

Microsoft Fabric には、Fabric Git 統合を使用したエンタープライズコンテンツの公開に関するその他のオプションが用意されています。 Git 統合を使用すると、Azure Repos リモートリポジトリ内のブランチに Fabric ワークスペースをリンクできます。そのブランチに保存されたコンテンツは、そのコンテンツがワークスペースに公開されたかのように、ワークスペースに自動的に同期されます。逆に、コンテンツ作成者は Fabric ワークスペースからリモートリポジトリに変更をコミットしてプッシュできます。

Git 統合により、コラボレーションとコンテンツの公開を効率化できますが、Fabric ワークスペースの使用方法とブランチ戦略を詳細に計画する必要があります。 Fabric Git 統合を設定して使用する方法の詳細については、「Git 統合の概要」または「チュートリアル: エンドツーエンドのライフサイクル管理」を参照してください。

シナリオ図

次の図は、エンタープライズコンテンツ公開をサポートする、最も一般的なユーザーアクションと Power BI コンポーネントの概要を示しています。ここで重要な点は、Azure DevOps を使って、Power BI サービスで開発、テスト、運用環境のワークスペースを介して、プログラムで大規模にコンテンツを管理および公開していることです。

ヒント

シナリオ図をプレゼンテーション、ドキュメント、またはブログの投稿に埋め込む場合、または壁のポスターとして印刷する場合は、シナリオ図をダウンロードすることをお勧めします。スケーラブルベクターグラフィックス (SVG) イメージであるため、品質を損なうことなくスケールアップまたはスケールダウンできます。

このシナリオ図は、次のユーザーアクション、プロセス、機能を示しています。

Item	説明
	コンテンツ作成者は、Power BI Desktop または Tabular Editor を使ってデータモデルを開発し、Power BI Desktop を使ってレポートを開発します。コンテンツ作成者は、開発中に作業内容をローカルリポジトリに保存します。
	コンテンツ作成者は、リモートリポジトリを複製して、そのコンテンツのローカルコピーを取得できます。
	一部のデータソースでは、プライベート組織ネットワーク内に存在するデータ更新のために、オンプレミスデータゲートウェイまたは VNet ゲートウェイが必要になる場合があります。
	コンテンツ作成者は Visual Studio Code などの Git クライアントを使って、開発中に定期的にコミットし、変更をリモートリポジトリにプッシュします。図では、リモートリポジトリは Azure Repos です。
	他のコンテンツ作成者は Azure Repos を使い、バージョン管理で変更を追跡します。変更を個別のブランチにコミットすることで共同作業します。
	リモートリポジトリのコンテンツが変更されると、Azure Pipelines がトリガーされます。検証パイプラインは、最初にトリガーされるパイプラインです。検証パイプラインは、公開前にコンテンツを検証する自動テストを実行します。
	検証パイプラインに合格したコンテンツは、後続のビルドパイプラインをトリガーします。ビルドパイプラインは、Power BI サービスに公開するコンテンツを準備します。この時点までのプロセスは、一般に "継続的インテグレーション" (CI) と呼ばれます。
	コンテンツのリリースとデプロイにはリリースパイプラインが使われます。リリースパイプラインは Power BI REST API またはワークスペース XMLA エンドポイントを使い、プログラムでコンテンツを Power BI サービスにインポートします。通常、リリースパイプラインを使ったデプロイは "継続的デプロイ" (CD) と呼ばれます。
	リリースマネージャーは、Azure Pipelines のリリース承認を使って、テストと運用環境のワークスペースに対するデプロイを管理します。通常、エンタープライズコンテンツ公開では、リリースマネージャーがテスト環境と運用環境へのコンテンツリリースを計画し、調整します。また、コンテンツ作成者、関係者、ユーザーとの間を調整し、コミュニケーションを取ります。
	リリースパイプラインは、開発ワークスペースにコンテンツを公開したり、開発ワークスペースからテストワークスペースにコンテンツを昇格したり、運用ワークスペースにテストしたりします。
	Fabric 容量ライセンスモードを含むワークスペースで作業しているコンテンツ作成者は、Git 統合を使用できます。 Git 統合により、コンテンツ作成者は開発中にプライベートワークスペースで作業できます。コンテンツ作成者は、Azure Repos から自身のプライベートワークスペースにリモートブランチ (通常は特定の機能ブランチまたはバグブランチ) を同期します。コンテンツの変更は、Azure Repos のリモートブランチとワークスペースの間で同期されます。このシナリオでは、コンテンツ作成者は Azure Pipelines を使用してコンテンツを公開する必要はありません。コンテンツ作成者は、公開後にワークスペースから変更を定期的にコミットしてプッシュすることもできます。準備ができたら、コンテンツ作成者は pull request (PR) を行って、変更をメインブランチにマージできます。
	Git 統合を使用する場合、開発ワークスペースはメインブランチと同期して、最新バージョンのコンテンツを取得します。このコンテンツには、リリースマネージャーが審査し、承認し、マージする pull request からのすべての変更が含まれます。
	ワークスペースは [Fabric 容量]、[Premium 容量]、または [Premium per user]、または [Embedded] ライセンスモードに設定され、Power BI デプロイパイプラインと XMLA の読み取り/書き込みエンドポイントを使用できます。
	デプロイパイプライン管理者は、開発、テスト、および運用の 3 つのステージで Power BI デプロイパイプラインを設定します。各ステージは、Power BI サービス内の別々のワークスペースに合わせて調整されます。デプロイの設定とアクセスは、デプロイパイプライン用に設定されます。
	開発ワークスペースには、承認およびマージされたすべての変更を含む最新バージョンのコンテンツが含まれます。承認されると、リリースパイプラインで開発からテストワークスペースにコンテンツがデプロイされます。
	テストワークスペース内のレビュー担当者は、コンテンツのテストと品質保証を実行します。承認されると、リリースパイプラインでテストワークスペースから運用ワークスペースにコンテンツがデプロイされます。 Git とデプロイパイプラインの統合を使用する場合、テストワークスペースはどのブランチとも同期しません。
	デプロイパイプラインのデプロイが完了すると、コンテンツ作成者は、デプロイ後のアクティビティを手動で実行します。アクティビティには、スケジュールされたデータ更新の設定や運用ワークスペースへの Power BI アプリの更新が含まれます。 Git とデプロイパイプラインの統合を使用する場合、運用ワークスペースはどのブランチとも同期しません。
	コンテンツ閲覧者は、運用ワークスペースまたは Power BI アプリを使ってコンテンツにアクセスします。

ヒント

セルフサービスコンテンツ公開と高度なデータモデル管理の使用シナリオも確認することをお勧めします。エンタープライズコンテンツ公開の使用シナリオは、これらのシナリオで導入された概念に基づいて構築されています。

重要なポイント

エンタープライズコンテンツの公開シナリオに関連して重視すべき重要なポイントを以下に示します。

バージョンコントロール

コンテンツのライフサイクル中の変更を追跡することは、コンシューマーに対する安定した一貫性のあるコンテンツ配信を確保するために重要です。この使用シナリオでは、コンテンツ作成者と所有者は、"バージョン管理" を使ってリモートリポジトリのコンテンツ変更を管理します。バージョン管理とは、ファイルやコードの変更を中央のリポジトリで管理するプラクティスです。このプラクティスにより、より良いコラボレーションとバージョン履歴の効果的な管理が可能になります。バージョン管理には、コンテンツ作成者にとって利点があります。たとえば、変更をロールバックまたはマージする機能などです。

通常、コンテンツ作成者は、より優れたバージョン管理をサポートするために Tabular Editor でデータモデルを開発します。 Power BI Desktop で開発したデータモデルとは異なり、Tabular Editor で開発したデータモデルは人間が判読できるメタデータ形式で保存されます。この形式なので、データモデルのオブジェクトレベルのバージョン管理が可能になります。複数の担当者が同じデータモデルで共同作業する場合は、オブジェクトレベルのバージョン管理を使う必要があります。詳細については、高度なデータモデル管理という使用シナリオのページを参照してください。レポート定義やデータモデルなど、Power BI Desktop ファイル (.pbix) に加えた変更は確認できません。たとえば、使われている視覚エフェクト、その位置、フィールドのマッピングや書式設定など、レポートページへの変更を追跡することはできません。

コンテンツ作成者は、データモデルメタデータファイルと .pbix ファイルを Azure Repos のような中央のリモートリポジトリに格納します。このようなファイルは "技術所有者" によって管理されます。コンテンツ作成者がソリューションを開発するのに対し、技術所有者はソリューションを管理し、変更点を確認し、1 つのソリューションにマージする作業を担当します。 Azure Repos には、変更を追跡し、管理するための高度なオプションが用意されています。このアプローチは、作成者がバージョン追跡付きの OneDrive ストレージを使うというセルフサービスコンテンツ公開の使用シナリオで説明されているアプローチとは異なります。すべてのコンテンツとコラボレーションの基盤になるので、適切にキュレーションし、文書化したリポジトリを保守することが不可欠です。

バージョン管理のためにリモートリポジトリを設定する上で役立つ重要な考慮事項の一部を次に示します。

スコープ: リポジトリのスコープを明確に定義します。リポジトリのスコープは、コンシューマーにコンテンツを提供するために使うダウンストリームのワークスペースやアプリのスコープと同じであることが理想的です。
アクセス: リポジトリへのアクセスは、デプロイパイプラインアクセス許可とワークスペースロールに設定したものと同様のアクセス許可モデルを使って設定するようにします。コンテンツ作成者にはリポジトリへのアクセス権が必要です。
ドキュメント: リポジトリにテキストファイルを追加して、その目的、所有権、アクセス、定義されたプロセスを記載します。たとえば、このドキュメントには変更のステージングとコミットの方法を記載できます。
ツール: コンテンツ作成者がリモートリポジトリにコミットして変更をプッシュするには、Visual Studio や Visual Studio Code などの Git クライアントが必要です。 Git は、ファイルの変更を追跡する分散バージョン管理システムです。 Git の基本については、「Git とは」を参照してください。

注意

Power BI Desktop ファイル (.pbix) をコミットする予定がある場合は、Git Large File Storage (LFS) を使うことを検討してください。 Git LFS には、.pbix ファイルのような変更を確認できない ("差分不可" ファイル) を管理するための高度なオプションが用意されています。たとえば、ファイルロックを使って、開発中の Power BI レポートの同時変更を防ぐことができます。ただし、Git LFS には独自のクライアントと構成があります。

Azure DevOps を使ったコラボレーション

ソリューションのスコープが広くなり、複雑になると、複数のコンテンツ作成者と所有者による共同作業が必要になる場合があります。コンテンツ作成者と所有者は、Azure DevOps を使うことで、中央の整理されたハブでコミュニケーションと共同作業を行います。

Azure DevOps で共同作業とコミュニケーションを行うには、サポートしているサービスを使います。

Azure Boards: コンテンツ所有者はボードを使って "作業項目" を追跡します。各作業項目はチームの 1 人の開発者に割り当てられます。また、ソリューションの問題、バグ、機能、対応する関係者が記載されています。
Azure Wiki: コンテンツ作成者は、チームと情報を共有してソリューションを理解し、貢献します。
Azure Repos: コンテンツ作成者は、リモートリポジトリの変更を追跡し、1 つのソリューションにマージします。
Azure Pipelines: パイプライン所有者は、自動またはオンデマンドでソリューションをデプロイするプログラムロジックを設定します。

コラボレーションフロー図

次の図は、エンタープライズコンテンツ公開の使用シナリオで、Azure DevOps でコラボレーションを実現する方法の例の 1 つの概要を示しています。この図の焦点は、Azure DevOps を使って、構造化され、文書化されたコンテンツ公開プロセスを作成することにあります。

この図は、次のユーザーアクション、プロセス、機能を示しています。

Item	説明
	コンテンツ作成者は、最新バージョンのコンテンツを含む main ブランチを複製することで、新しい有効期間の短いブランチを作成します。新しいブランチは、特定の機能の開発や特定の問題の修正に使用されるため、多くの場合、機能ブランチと呼ばれます。
	コンテンツ作成者は開発中に変更をローカルリポジトリにコミットします。
	コンテンツ作成者は変更を Azure Boards で管理されている作業項目にリンクします。作業項目には、ブランチにスコープされた特定の開発、改善、またはバグ修正を記述します。
	コンテンツ作成者は定期的に変更をコミットします。準備ができたら、コンテンツ作成者はブランチをリモートリポジトリに公開します。
	コンテンツ作成者は、変更をテストするために、ソリューションを開発用に分離されたワークスペース (この図には示されていません) にデプロイします。コンテンツ作成者は、Fabric Git 統合を使用して機能ブランチをワークスペースに同期することもできます。
	コンテンツ作成者とコンテンツ所有者は、ソリューションとそのプロセスを Azure Wiki に記載し、開発チームの全員が使用できるようにします。
	準備ができたら、コンテンツ作成者は pull request を開いて、機能ブランチを main ブランチにマージします。
	技術所有者は、pull request を確認し、変更をマージする作業を担当します。 pull request を承認したら、機能ブランチを main ブランチにマージします。
	マージに成功すると、Azure Pipeline を使用したソリューションの開発ワークスペース (この図には示されていません) へのデプロイがトリガーされます。 Fabric Git 統合を使用すると、main ブランチは開発ワークスペースに同期されます。
	リリースマネージャーがソリューションの最終レビューと承認を行います。このリリース承認により、準備が整う前にソリューションがリリースされるのを防ぐことができます。通常、エンタープライズコンテンツ公開では、リリースマネージャーがテストおよび運用ワークスペースへのコンテンツリリースを計画し、調整します。また、コンテンツ作成者、関係者、ユーザーとの間を調整し、コミュニケーションを取ります。
	リリースマネージャーがリリースを承認すると、Azure Pipelines でソリューションのデプロイが自動的に準備されます。または、Azure Pipeline でデプロイパイプラインをトリガーして、ワークスペース間でコンテンツのレベルを上げることもできます。
	ユーザーは、テストワークスペースのコンテンツをテストして検証します。デプロイに Git と Azure Pipelines の統合を使用する場合、テストワークスペースはどのブランチとも同期しません。
	ユーザーが変更を受け入れて検証すると、リリースマネージャーはソリューションの最終的なレビューと承認を実行して、運用ワークスペースにデプロイします。
	ユーザーは、運用ワークスペースに公開されたコンテンツを表示します。デプロイに Git と Azure Pipelines の統合を使用する場合、運用ワークスペースはどのブランチとも同期しません。

詳しく説明すると、コンテンツ作成者は "分岐戦略" を使ってコラボレーションを実現します。ブランチ戦略とは、コンテンツの変更を効果的に行って管理するために、コンテンツ作成者がブランチを作成、使用、マージする方法です。個々のコンテンツ作成者は、自分のローカルリポジトリで独立して作業します。準備ができたら、リモートリポジトリで 1 つのソリューションとして変更を結合することができます。コンテンツ作成者は、特定の開発、改善、バグ修正の作業項目にリンクすることで、ブランチに作業のスコープを設定する必要があります。各コンテンツ作成者は、リモートリポジトリに作業スコープに対応した独自のブランチを作成します。ローカルソリューションで行った作業は、"コミットメッセージ" を使ってリモートリポジトリにあるブランチのバージョンにコミットし、プッシュします。コミットメッセージには、そのコミットで加えられた変更を記述します。

変更をマージするには、コンテンツ作成者が pull request を開きます。 pull request とはピアレビューの送信です。この結果、行われた作業が 1 つのソリューションにマージされます。マージによって競合が生じる可能性があります。ブランチをマージするには、これを解決する必要があります。 pull request のレビューは、開発、品質、コンプライアンスに関する組織の標準やプラクティスを作成者が順守していることを確認するために重要です。

コラボレーションに関する推奨事項

コンテンツ作成者がどのように共同作業すべきかについて、構造化されたプロセスを定義することをお勧めします。次のことを決めてください。

作業のスコープ設定方法と、ブランチの作成、名前付け、使用の方法。
作成者が変更をグループ化し、コミットメッセージで説明する方法。
pull request のレビューと承認の担当者。
マージの競合を解決する方法。
異なるブランチで行われた変更を 1 つのブランチにマージする方法。
コンテンツをテストする方法と、コンテンツのデプロイ前にテストを実行する担当者。
開発、テスト、運用環境のワークスペースに変更をデプロイする方法とタイミング。
デプロイ済みの変更またはソリューションのバージョンをロールバックする方法とタイミング。

重要

DevOps で実現できる価値は、その使用を定義したプロセスの順守に正比例します。

コラボレーションの成功は、明確に定義されたプロセスにかかっています。エンドツーエンドの開発ワークフローを明確に説明し、文書化することが重要です。選んだ戦略とプロセスがチームの既存のプラクティスと一致していることを確認し、一致していない場合は、変更をどのように管理するかを確認します。さらに、そのプロセスが明確であり、すべてのチームメンバーと関係者に伝達されていることを確認します。プロセスについて初めて知るメンバーや関係者には、その導入方法をトレーニングし、DevOps の導入が成功することの価値を理解できるようにします。

Power BI REST API

Power BI REST API を使って Azure DevOps からコンテンツをインポートし、デプロイするプログラムロジックを開発します。インポート操作を使って Power BI ファイル (.pbix) をワークスペースにインポートします。 Power BI デプロイパイプラインを使い、パイプライン操作を使って一部のコンテンツまたはすべてのコンテンツをテストまたは運用環境のワークスペースにデプロイします。このプログラムロジックは Azure Pipelines で定義されています。

パイプラインで Power BI REST API を呼び出すには、サービスプリンシパルを使うことをお勧めします。サービスプリンシパルは、ユーザー操作を伴わない自動アクティビティを想定しており、ユーザーの資格情報には依存しません。ただし、データフローのように、Power BI REST API やサービスプリンシパルの使用時にサポートされない項目やアクティビティもあります。

サービスプリンシパルを使う場合は、アクセス許可を慎重に管理してください。最小限の特権の原則に従うことを目指す必要があります。アクセス許可を過剰にプロビジョニングすることなく、十分なアクセス許可をサービスプリンシパルに設定する必要があります。サービスプリンシパルのシークレットと資格情報をセキュリティで保護された方法で格納する Azure Key Vault または他のサービスを使ってください。

注意事項

人間が判読できるメタデータ形式で保存されているデータモデルがある場合、Power BI REST API を使ってそれを公開することはできません。代わりに、XMLA エンドポイントを使って公開する必要があります。 Tabular Editor コマンドラインインターフェイス (CLI) などのサードパーティツールを使ってメタデータファイルを公開できます。また、独自のカスタム .NET 開発を使って、メタデータファイルをプログラムで公開することもできます。カスタムソリューションの開発には、Analysis Management Object (AMO) クライアントライブラリの Microsoft Tabular Object Model (TOM) 拡張機能を使う必要があるため、より多くの労力が必要です。

Azure Pipelines

Azure Pipelines を使うと、コンテンツのテスト、管理、デプロイをプログラムで自動化できます。パイプラインを実行すると、パイプラインの手順が自動実行されます。パイプライン所有者は、デプロイのニーズに合わせてトリガー、手順、機能をカスタマイズできます。そのため、パイプラインの数や種類はソリューションの要件によって異なります。たとえば、Azure Pipeline を使うと、デプロイ前に自動テストを実行することや、データモデルパラメーターを変更することができます。

Power BI ソリューションのテスト、管理、デプロイの目的で設定できる 3 種類の Azure パイプラインがあります。

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

注意

これらの 3 つのパイプラインすべてを公開ソリューションに含める必要はありません。ワークフローやニーズに応じて、この記事で説明したパイプラインの 1 種類以上を設定してコンテンツの公開を自動化できます。このようにパイプラインをカスタマイズできることが、組み込みの Power BI デプロイパイプラインよりも Azure Pipelines が優れている点です。たとえば、検証パイプラインを含める必要はありません。ビルドパイプラインとリリースパイプラインのみを使用できます。

検証パイプライン

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

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

ビルドパイプライン

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

リリースパイプライン

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

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

テストとリリースのパイプラインでコンテンツを公開するには、2 種類のアプローチがあります。 Power BI デプロイパイプラインを使ってコンテンツを昇格する方法、または Azure DevOps から Power BI サービスにコンテンツを公開する方法です。

次の図は 1 つ目のアプローチを示しています。このアプローチで、リリースパイプラインは Power BI デプロイパイプラインを使って、テストと運用環境のワークスペースへのコンテンツのデプロイを調整します。コンテンツは、Power BI の開発、テスト、運用環境のワークスペースを介して昇格されます。このアプローチはより堅牢であり、保守が簡単ですが、Premium ライセンスが必要です。

この図は、1 つ目のアプローチの次のユーザーアクション、プロセス、機能を示しています。

Item	説明
	1 つ目のアプローチでは、リリースパイプラインは、XMLA エンドポイントと Power BI REST API を Power BI デプロイパイプラインで使ってコンテンツを公開します。コンテンツは公開され、次に開発、テスト、運用環境のワークスペースを介して昇格されます。 Power BI デプロイパイプラインと XMLA 読み取り/書き込みエンドポイントは Premium 機能です。
	ブランチのマージの成功またはアップストリームパイプラインの完了によって、ビルドパイプラインがトリガーされます。次に、ビルドパイプラインは公開のためにコンテンツを準備し、開発リリースパイプラインをトリガーします。
	開発リリースパイプラインは、XMLA エンドポイント (データモデルメタデータの場合) または Power BI REST API (データモデルやレポートを含む可能性がある Power BI Desktop ファイルの場合) を使ってコンテンツを開発ワークスペースに公開します。開発パイプラインは、Tabular Editor コマンドラインインターフェイス (CLI) を使い、XMLA エンドポイントを使ってデータモデルメタデータをデプロイします。
	リリースの承認またはオンデマンドのトリガーにより、テストリリースパイプラインがアクティブになります。
	テストリリースパイプラインは、Power BI REST API のデプロイ操作を使ってコンテンツをデプロイします。これにより、Power BI デプロイパイプラインが実行されます。
	Power BI デプロイパイプラインでは、開発ワークスペースからテストワークスペースにコンテンツを昇格します。デプロイ後に、リリースパイプラインは Power BI REST API を使ってデプロイ後のアクティビティを実行します (図には示されていません)。
	リリースの承認またはオンデマンドのトリガーにより、運用環境リリースパイプラインがアクティブになります。
	運用環境リリースパイプラインは、Power BI REST API のデプロイ操作を使ってコンテンツをデプロイします。これにより、Power BI デプロイパイプラインが実行されます。
	Power BI デプロイパイプラインでは、テストワークスペースから運用環境ワークスペースにコンテンツを昇格します。デプロイ後に、リリースパイプラインは Power BI REST API を使ってデプロイ後のアクティビティを実行します (図には示されていません)。

次の図は 2 つ目のアプローチを示しています。このアプローチではデプロイパイプラインを使いません。代わりに、リリースパイプラインを使って、Azure DevOps からテストおよび運用環境ワークスペースにコンテンツを公開します。この 2 つ目のアプローチで特筆すべき点は、Power BI REST API を使って Power BI Desktop ファイルのみを公開する場合は Premium ライセンスが必要ないことです。ただし、Power BI の外部でデプロイを管理する必要があるため、設定作業が増え、複雑になります。 Power BI の外部のデータソリューションに DevOps を既に使っている開発チームであれば、このアプローチになじみがあるかもしれません。このアプローチを使う開発チームは、データソリューションのデプロイを Azure DevOps に統合できます。

この図は、2 つ目のアプローチの次のユーザーアクション、プロセス、機能を示しています。

Item	説明
	2 つ目のアプローチで、リリースパイプラインは XMLA エンドポイントと Power BI REST API のみを使ってコンテンツを公開しています。コンテンツは、開発、テスト、運用環境のワークスペースに公開されます。
	ブランチのマージの成功またはアップストリームパイプラインの完了によって、ビルドパイプラインがトリガーされます。次に、ビルドパイプラインは公開のためにコンテンツを準備し、開発リリースパイプラインをトリガーします。
	開発リリースパイプラインは、XMLA エンドポイント (データモデルメタデータの場合) または Power BI REST API (データモデルやレポートを含む可能性がある Power BI Desktop ファイルの場合) を使ってコンテンツを開発ワークスペースに公開します。開発パイプラインは、Tabular Editor コマンドラインインターフェイス (CLI) を使い、XMLA エンドポイントを使ってデータモデルメタデータをデプロイします。
	リリースの承認またはオンデマンドのトリガーにより、テストリリースパイプラインがアクティブになります。
	開発リリースパイプラインは、XMLA エンドポイント (データモデルメタデータの場合) または Power BI REST API (データモデルやレポートを含む可能性がある Power BI Desktop ファイルの場合) を使ってコンテンツをテストワークスペースに公開します。開発パイプラインは、Tabular Editor コマンドラインインターフェイス (CLI) を使い、XMLA エンドポイントを使ってデータモデルメタデータをデプロイします。デプロイ後に、リリースパイプラインは Power BI REST API を使ってデプロイ後のアクティビティを実行します (図には示されていません)。
	リリースの承認またはオンデマンドのトリガーにより、運用環境リリースパイプラインがアクティブになります。
	開発リリースパイプラインは、XMLA エンドポイント (データモデルメタデータの場合) または Power BI REST API (データモデルやレポートを含む可能性がある Power BI Desktop ファイルの場合) を使ってコンテンツを運用環境ワークスペースに公開します。開発パイプラインは、Tabular Editor コマンドラインインターフェイス (CLI) を使い、XMLA エンドポイントを使ってデータモデルメタデータをデプロイします。デプロイ後に、リリースパイプラインは Power BI REST API を使ってデプロイ後のアクティビティを実行します (図には示されていません)。

リリースパイプラインではデプロイ後のアクティビティを管理する必要があります。このアクティビティには、セマンティックモデル資格情報の設定や、テストと運用環境のワークスペース用 Power BI アプリの更新などがあります。デプロイのアクティビティを関係者に情報を提供するために通知を設定することをお勧めします。

ヒント

バージョン管理にリポジトリを使うことで、コンテンツ作成者はロールバックプロセスを作成できます。ロールバックプロセスを使うと、以前のバージョンを復元して最後のデプロイを元に戻すことができます。運用環境の変更をロールバックする処理をトリガーできる Azure Pipelines の個別のセットを作成することを検討してください。ロールバックを開始するためにどのようなプロセスと承認が必要かについて慎重に検討してください。このようなプロセスは必ず文書化します。

Power BI デプロイパイプライン

Power BI デプロイパイプラインは、開発、テスト、運用の 3 つのステージで構成されます。デプロイパイプラインの各ステージに 1 つの Power BI ワークスペースを割り当てます。デプロイが発生すると、デプロイパイプラインは Power BI 項目をあるワークスペースから別のワークスペースに昇格します。

Azure Pipelines リリースパイプラインは Power BI REST API を使い、Power BI デプロイパイプラインを使ってコンテンツをデプロイします。デプロイを実行するユーザーには、ワークスペースとデプロイパイプラインの両方へのアクセス権が必要です。パイプラインユーザーがデプロイ履歴を表示し、コンテンツを比較できるように、デプロイパイプラインのアクセスを計画することをお勧めします。

ヒント

データワークスペースとレポートワークスペースを分ける場合は、Azure Pipelines を使って、複数の Power BI デプロイパイプラインによるコンテンツの公開を調整することを検討してください。セマンティックモデルは最初にデプロイされ、次に更新されます。最後に、レポートがデプロイされます。このアプローチにより、デプロイを簡略化できます。

Premium ライセンス

Power BI デプロイパイプラインと XMLA 読み取り/書き込みエンドポイントは Premium 機能です。これらの機能は、Power BI Premium 容量と Power BI Premium Per User (PPU) で使用できます。

一般に、PPU は、ユーザー数が少ない開発およびテストのワークスペースに適した、エンタープライズコンテンツ公開を管理する場合に費用対効果の高い方法です。このアプローチには、開発とテストのワークロードを運用環境ワークロードから分離できるという利点もあります。

注意

リリースパイプラインセクションの 2 つ目のアプローチで説明したように、Premium ライセンスがなくてもエンタープライズコンテンツ公開は設定できます。 2 つ目のアプローチでは、Azure Pipelines を使って、開発、テスト、運用環境のワークスペースへの Power BI Desktop ファイルのデプロイを管理します。ただし、Power BI REST API を使ってメタデータ形式のセマンティックモデルを公開することはできないため、XMLA エンドポイントを使ってモデルのメタデータをデプロイすることはできません。また、デプロイパイプラインがある環境を介してコンテンツを昇格するには、Premium ライセンスが必要です。

ゲートウェイの設定

通常は、組織のプライベートネットワークまたは仮想ネットワーク内に存在するデータソースにアクセスする際に、データゲートウェイが必要です。ゲートウェイの 2 つの目的は、インポートされたデータを更新することと、ライブ接続または DirectQuery セマンティックモデル (シナリオ図では示されていない) を照会するレポートを表示することです。

複数の環境で作業する場合は、さまざまなソースシステムに合わせて開発、テスト、運用の接続を設定するのが一般的です。その場合は、データソースルールとパラメータールールを使用して、環境間で異なる値を管理します。 Azure Pipelines を使ってゲートウェイを管理するには、Power BI REST API のゲートウェイ操作を使います。

注意

"個人モード" でゲートウェイを使用するよりも、"標準モード" で一元管理されたデータゲートウェイを使用する方が強く推奨されています。標準モードのデータゲートウェイでは、(スケジュールされたデータ更新操作に加えて) ライブ接続と DirectQuery 操作もサポートされています。

システム監視

アクティビティログには、Power BI サービス内で発生したイベントが記録されます。 Power BI 管理者はアクティビティログを使ってデプロイアクティビティを監査することができます。

Power BI のメタデータスキャン API を使って、テナントインベントリを作成できます。 API の結果は、各ワークスペースにデプロイされた項目を確認する場合、系列を確認する場合、セキュリティ設定を確認する場合に役立ちます。

また、Azure DevOps 内にも監査ログがあります。これは Power BI サービスの外部にあります。 Azure DevOps 管理者はこの監査ログを使って、リモートリポジトリとパイプラインのアクティビティを確認できます。

Power BI 実装の決定に役立つその他の有益なシナリオについては、「Power BI 使用シナリオ」の記事を参照してください。

次の方法で共有

Power BI の使用シナリオ: エンタープライズコンテンツの公開

シナリオ図