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 ステージを強調表示しています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fabric Git 統合を使用して公開する

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

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

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

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

Azure Pipelines を使用して公開する

Azure Pipelines を使うと、コンテンツのテスト、管理、デプロイをプログラムで自動化できます。 パイプラインを実行すると、パイプラインの手順が自動実行されます。 Azure Pipelines はより複雑であるため、設定のために他のアプローチと比較して多くの時間と作業が必要ですが、展開プロセスを調整するための制御と柔軟性は最も高くなります。

次の場合は、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 エンドポイントを使用してセマンティック モデルを展開できます。

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

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

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

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

検証パイプライン

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

自動テストの例としては、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 つの展開パイプライン内で後のステージに昇格させる場合です。 次の図は、展開パイプラインを使用してコンテンツを展開するためのこの最初のアプローチを示しています。

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

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

次の図は、複数の展開パイプラインを使用してコンテンツを展開するためのこの 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 から展開パイプラインを調整する方法を示しています。

要約すると、コンテンツ作成者は、展開パイプラインの第 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 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 統合を使用してコンテンツを展開する方法を示しています。 わかりやすくするために、この図にコンテンツのブランチまたはマージの詳細は含まれていません。

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

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

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

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

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

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

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

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

関連するコンテンツ

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