Power BI 実装計画: コンテンツ開発と変更管理

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

• センター オブ エクセレンス (COE)、BI チーム: 組織内で Power BI の監視を担当するチーム。 これらのチームには、Power BI コンテンツのライフサイクル管理の方法を決める意思決定者が含まれます。 また、コンテンツ リリースのライフサイクルを扱うリリース マネージャーや、ライフサイクル管理の効果的な利用とサポートのために必要なコンポーネントの作成と管理を担うエンジニアなども含まれる可能性があります。
• コンテンツ作成者とコンテンツ所有者: コンテンツを作成し、Fabric ポータルに発行して他者と共有するユーザー。 これらの人々は、自分が作成する Power BI コンテンツのライフサイクル管理について責任を負います。

ライフサイクル管理とは、コンテンツが生まれてから役割を終えるまでの全期間を含めた、コンテンツの取り扱いに関するプロセスとプラクティスです。 ライフサイクル管理の第 1 ステージは、コンテンツの計画と設計です。これには、ソリューション計画と、ライフサイクル管理のアプローチを左右する重要な意思決定が含まれます。 第 2 ステージは、コンテンツの開発と変更管理です。

ライフサイクルが継続する間、コンテンツの変更管理を続けることは、コンテンツ作成者間のコラボレーションを効果的に行い、利用者に対するコンテンツ供給の安定性、一貫性を確保するために重要です。

次の図は Power BI コンテンツのライフサイクルを表しており、特に、第 2 ステージ、コンテンツ開発と変更管理を強調したものです。

コンテンツの作成者や所有者には、バージョン管理を使用してコンテンツの変更管理を行うことが推奨されます。 バージョン管理とは、ファイルやコードの変更を中央のリポジトリで管理するプラクティスです。 これは、よりスムーズで効果的なコラボレーションとコンテンツ管理の実現に役立ちます。

その他、バージョン管理には以下のメリットがあります。

• 複数のコンテンツ作成者による変更をマージし、マージの競合に対処することができます。
• 変更されたコンテンツはどれなのか、コンテンツの変更箇所はどこなのかを特定できます。
• コンテンツの変更内容と特定の作業項目とを関連付けることができます。
• 多数の変更点をグループ化し、バージョン履歴付きの異なるリリースに分類できます。
• コンテンツの変更内容やバージョン全体をロールバックできます。

バージョン管理をセットアップする際の最初のステップは、コンテンツの開発方法を決定することです。

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

コンテンツをどのような方法で作成するかは、管理方法についての意思決定に影響します。 たとえば、Power BI レポートとセマンティック モデルでは、Power BI Desktop (.pbix) ファイルを使用する場合のバージョン管理は、Power BI Desktop プロジェクト (.pbip) 形式の場合と比べて選択肢が少なくなります。 これは、.pbix ファイルがバイナリ形式であるのに対し、.pbip 形式は、人間が判読できるコンテンツとメタデータを含んだテキスト ベースの形式だからです。 人間が判読できるコンテンツとメタデータを使用するほうが、ソース管理によってモデルとレポートの変更を追跡管理することが容易になります。 ソース管理においては、コンテンツのコードとメタデータの内部まで変更箇所の確認と管理を行うことができます。

Power BI Desktop

Power BI Desktop では、セマンティック モデルまたはレポートを作成し、.pbix ファイルまたは .pbip ファイルとして保存できます。 また、Power BI Desktop の使用時には追加のカスタム コンテンツ ファイルをあわせて使用することもできます。Power BI Desktop でコンテンツを作成する場合、必要となる主な意思決定事項は以下のようなものです。

• 使用するファイル形式: コンテンツの保存形式としては、.pbix ファイルまたは .pbip ファイルを選択できます。 たとえば、Git 統合には .pbip ファイルの使用が必須ですが、セルフサービスの作成者にとっては、Teams、SharePoint、または OneDrive で .pbix ファイルの管理と保守を行うほうが簡単で好都合である可能性もあります。
• カスタム コンテンツの管理方法: Power BI Desktop ファイルにはテーマ、カスタム ビジュアル、画像を追加できますが、そのようなファイルのライフサイクル管理に関して特有の考慮事項が発生することがあります。 たとえば、コンテンツ作成者が独自のカスタム ビジュアルを作成する際には、ビジュアル定義を別のファイルに保存し、分けて管理することが推奨されます。
• プレビュー機能の管理方法: Power BI Desktop のプレビューに関する機能や設定を活用すると、コンテンツの表示形態や利用方法を目的に応じて変更できます。 たとえば、プレビュー機能の対象となるコンテンツに追加の検証手順を適用することができます。

Web オーサリング

データフロー、ダッシュボード、スコアカードなどのような種類のコンテンツは、Fabric ポータルでのみ作成できます。 一方、セマンティック モデル、レポート、ページ割り付けレポートなど、Fabric ポータルとローカル ツールのどちらでも作成や変更を行える種類のコンテンツもあります。 Web オーサリングでコンテンツを作成する場合、必要となる主な意思決定事項は以下のようなものです。

• 変更管理の方法: Web オーサリングではさまざまな種類のアイテムに変更を加えることができますが、場合によっては、直ちに以前のバージョンを上書きして変更内容が保存される可能性があります。 したがって、他のユーザーとの共同作業時には Web オーサリングで共有アイテムを直接編集せず、作業用のコピーを作成することが望ましい場合があります。
• コンテンツのバックアップを保存する方法: Web オーサリングでは、レポートやセマンティック モデルなどのコンテンツを作成できますが、それらのアイテムをローカルの .pbix ファイルにダウンロードすることはできません。 そのようなコンテンツをバックアップするには、メタデータを取得して保存する方法などが考えられます。

その他のツール

作成と管理には、コンテンツの種類に応じて他のツールを使用できることがあります。 他のツールを使用する理由としては、別のメリットが得られること、お使いのワークフローへの適合性が高いこと、特定の機能やコンテンツ タイプの管理に必須であることなどが考えられます。 他の Microsoft ツールとサードパーティ ツールの両方を併用してコンテンツの作成と管理を行うこともできます。 コンテンツの作成と管理に使用できる他のツールとしては以下のようなものがあります。

• Visual Studio または Visual Studio Code: 開発者向けの統合開発環境。セマンティック モデルまたは Fabric ノートブックの作成と管理が可能です。 また、Visual Studio と Visual Studio Code の両方を使用してソース コントロール管理 (SCM) を行い、ローカルでの変更内容をコミット操作でリモート リポジトリにプッシュすることもできます。
• 表形式エディター: セマンティック モデルの開発と管理ができるサードパーティ製ツール。
• Excel: セマンティック モデルで扱えるピボット テーブルやライブ接続されたテーブルのためのクライアント ツール。
• Power BI Report Builder: ページ割り付けレポート (.rdl) ファイルを作成するためのデスクトップ アプリケーション。

他のツールでコンテンツを作成する場合、必要となる主な意思決定事項は以下のようなものです。

• ライセンスの管理方法: 他のツールについては、追加のライセンスとその管理が必要になる場合があります。
• コンテンツの発行方法: 他のツールについては、コンテンツの発行時に追加の手順 (たとえば、XMLA エンドポイントや Power BI REST API を使用することなど) が必要な場合があります。

コンテンツの作成方法を決定した後は、コンテンツの開発中に発行とテストを行う場所の選択が必要になります。

ワークスペースのセットアップと使用方法を決定する

コンテンツの開発時には、組織で使われる運用コンテンツと開発中または検証中のコンテンツを分けるために複数のワークスペース (またはステージ) を使用することをお勧めします。 コンテンツ用に別個のワークスペースを複数用意することには以下のような利点があります。

• 実際に使われている現行コンテンツに影響を与えることなく、コンテンツの開発やテストができます。 運用環境のコンテンツに、変更の影響で意図しない利用中断が発生することを回避できます。
• コンテンツの開発とテストに別のリソースを使用できます (たとえば、別のデータ ゲートウェイ、別の Fabric 容量などを用意できます)。 このため、開発用やテスト用のリソースによって運用ワークロードが中断されるのを防ぎ、データ更新やレポート作成に遅れが出ることを回避できます。
• コンテンツ開発、テスト、リリースに関するプロセスの構造化のレベルを高め、これらの段階ごとに異なる環境を用意できます。 このことは生産性の向上に役立ちます。

Fabric と Power BI では、テナント レベルとワークスペース レベルの計画に関する記事で説明されているように、複数の Fabric ワークスペースを使い分けることをお勧めします。

Fabric ワークスペースを使用して環境を分けるには複数の方法があります。 一般的には、ローカル環境に加えて 2 つ以上のワークスペースが用意され、コンテンツ ライフサイクルの中でコンテンツ管理に使用されます。

複数のワークスペースをコンテンツ ライフサイクル全体の中でどう使うかを計画する際には、以下の質問に答えていくとよいでしょう。

• ワークスペースはいくつ必要ですか?
• アイテムの種類別にワークスペースを分けますか?
• どのワークスペースに誰がアクセスしますか?
• これらのワークスペースは Fabric デプロイ パイプラインに属しますか? それとも、別のアプローチ (Azure Pipelines など) によってデプロイのオーケストレーションを行いますか?
• クロス ワークスペースでの発行をどのように管理しますか? たとえば、レポート用テスト ワークスペース内にあるレポートと、別のデータ アイテム用テスト ワークスペース内にあるセマンティック モデルとの間に、接続が確実に成り立っている必要がありますか?
• また、運用ワークスペース内のアイテムのために別のサポート リソース (別のオンプレミス データ ゲートウェイ クラスターなど) を使用する必要がありますか?

以降のセクションでは、別々のワークスペースを活用してライフサイクル管理をしやすくする各種のアプローチについて、それぞれの概要を説明します。

テスト ワークスペースと運用ワークスペース

組織にとってクリティカルではないシンプルなコンテンツのデプロイには、多くの場合、2 つのワークスペースで十分です。 このシナリオの場合、コンテンツ作成者はコンテンツ開発作業をローカルで行い、同じアイテムについて複数人が共同作業を行う機会は限られているのが一般的です。

次の図は、テスト ワークスペースと運用ワークスペースの 2 つのみを使用して環境を分離する例の概略を示しています。

この図は、このアプローチでワークスペースを分離する場合に関する、以下のプロセスと構成要素を示しています。

品目	説明
	コンテンツ作成者は、ローカル環境でコンテンツを開発します。
	準備ができたら、コンテンツ作成者はコンテンツをテスト ワークスペースに発行します。 コンテンツ作成者は、作成方法の選択肢が Web オーサリングのみであるようなコンテンツを開発し、テスト ワークスペースでコンテンツ検証を実行できます。
	準備ができたら、コンテンツ作成者はコンテンツを運用ワークスペースにデプロイします。 コンテンツ作成者が運用ワークスペースでコンテンツを配布するには、Power BI アプリを発行するか、ワークスペースからコンテンツを共有します。

開発、テスト、運用のワークスペース

ビジネス上クリティカルなコンテンツの配信には、3 つ以上のワークスペースを使用するのが一般的です。 このシナリオでは、多くの場合、コンテンツ作成者は最新バージョンのソリューションを含んだ追加の開発ワークスペース内で共同作業を行います。

次の図は、開発、テスト、運用の 3 つのワークスペースを使用して環境を分離する例の概略を示しています。

この図は、このアプローチでワークスペースを分離する場合に関する、以下のプロセスと構成要素を示しています。

品目	説明
	コンテンツ作成者は、ローカル環境でコンテンツを開発します。
	準備ができたら、コンテンツ作成者はコンテンツを開発ワークスペースに発行します。 開発ワークスペースでは、コンテンツ作成者は、作成方法の選択肢が Web オーサリングのみであるようなコンテンツを開発できます。 コンテンツ作成者は、開発ワークスペースでコンテンツを検証することもできます。
	準備ができたら、コンテンツ作成者はコンテンツをテスト ワークスペースにデプロイします。 テスト ワークスペースでは、ユーザーがワークスペース内またはアプリ内のコンテンツを検証します。
	準備ができたら、コンテンツ作成者はコンテンツを運用ワークスペースにデプロイします。 コンテンツ作成者が運用ワークスペースでコンテンツを配布するには、Power BI アプリを発行するか、ワークスペースからコンテンツを共有します。

プライベート ワークスペースと Git 統合

ビジネス上クリティカルなコンテンツの配信では、開発者が各自の開発用プライベート ワークスペースを使用することもできます。 このシナリオでは、それぞれのコンテンツ作成者がプライベート ワークスペースを持つことで、他の開発チーム メンバーの作業を中断させるリスクを冒すことなく、Fabric ポータルでコンテンツをテストすることや、スケジュールされた更新などの機能を利用することができます。 また、こちらの Fabric ポータルでデータフローなどのコンテンツを開発することもできます。 プライベート ワークスペースは、Git 統合と Azure DevOps を組み合わせてコンテンツの変更管理を行う場合にも適しています。

次の図は、プライベート ワークスペースと Git 統合を使用して環境を分離する例の概略を示しています。

この図は、このアプローチでワークスペースを分離する場合に関する、以下のプロセスと構成要素を示しています。

品目	説明
	各コンテンツ作成者は、自分用のローカル環境でコンテンツを開発します。
	準備ができたら、コンテンツ作成者は変更をコミットし、リモート リポジトリ (Azure Repos Git リポジトリなど) にプッシュします。
	リモート Git リポジトリでは、コンテンツ作成者はソース管理を使用してコンテンツの変更管理を行い、共同作業の便宜のためにコンテンツのブランチ化やマージを行います。
	コンテンツ作成者は、リモート リポジトリのブランチをプライベート ワークスペースと同期します。 作成者がコミットしてブランチにプッシュした最新の変更内容は、同期されると、そのプライベート ワークスペースに反映されます。 異なるコンテンツ作成者はそれぞれ自分のブランチで作業し、変更を加えていきます。
	プライベート ワークスペースで、コンテンツ作成者は Web オーサリングを使用してコンテンツを開発し、自分が加えた変更を検証できます。 Web オーサリングでコンテンツに加えられた変更内容は、コンテンツ作成者が変更をコミットしてワークスペースからプッシュすると、Git リポジトリ内のブランチに同期されます。 異なるコンテンツ作成者はそれぞれ自分のプライベート ワークスペースで作業を進めます。
	準備ができたら、コンテンツ作成者は pull request を実行して、自分の変更内容をソリューションのメイン ブランチにマージします。
	変更内容をマージすると、メイン ブランチは開発ワークスペースと同期されます。
	開発ワークスペースでは、コンテンツ作成者は Fabric Git 統合でサポートされていないコンテンツ (ダッシュボードなど) を開発できます。 また、最新の変更をすべて含んだ統合ソリューションを検証することができます。
	準備ができたら、コンテンツ作成者はコンテンツをテスト ワークスペースにデプロイします。 テスト ワークスペースでは、ユーザーがコンテンツのユーザー受け入れテストを実行します。
	準備ができたら、コンテンツ作成者はコンテンツを運用ワークスペースにデプロイします。 コンテンツ作成者が運用ワークスペースでコンテンツを配布するには、Power BI アプリを発行するか、ワークスペースからコンテンツを共有します。

ワークスペースのサポート リソース

分離した環境を使用する際には、それらの環境内で使用するさまざまなサポート リソースについても、環境の分離によってどのような影響が生じるかを検討する必要があります。 サポート リソースを同じ数のステージに分割する必要があるかどうか、また、複数の環境間でリソースを共用する場合はその調整をどのように行うかを検討してください。

• ゲートウェイ: 運用ワークロードのためのオンプレミス データ ゲートウェイ クラスターと VNet ゲートウェイを別途用意することを検討してください。 これには、利用中断を予防できるだけでなく、ゲートウェイの更新が必要になったときにアップタイムを維持できるメリットがあります。
• アプリ: テスト ワークスペースと運用ワークスペースのアプリは別々に用意することを検討してください。 ステージをまたいでアプリをデプロイまたはコピーすることはできません。 テスト ワークスペースにアプリを配置する目的は、変更を運用ワークスペースにデプロイする前にコンテンツとアプリ エクスペリエンスをテストすることです。 運用ワークスペースにアプリを配置する目的は、エンド ユーザー向けにコンテンツを配信し、構造化されたエクスペリエンスの中で提供することです。
• Azure DevOps: ソース管理とデプロイに関する共同作業とオーケストレーションに Azure DevOps を使用する場合は、ブランチと Azure Pipelines を使用して複数の環境にコンテンツをデプロイする方法を検討してください。 Azure Pipelines を使用してコンテンツをデプロイする方法の詳細については、「ステージ 4: コンテンツをデプロイする」を参照してください。

ワークスペースのセットアップと使用方法を決定した後は、次の手順として、コンテンツの変更を追跡および管理するためのバージョン管理の実行方法を決定します。

バージョン管理の使用方法を決定する

Power BI で バージョン管理を実行するには、SharePoint または OneDrive を使用する方法と、リモート Git リポジトリ (Azure DevOps のコンポーネントである Azure Repos など) を使用する方法があります。 どちらの場合も、ローカル コンテンツ ファイルをリモート ストレージの場所に追加して変更管理に役立てることができます。 SharePoint と OneDrive は、小規模でシンプルなプロジェクトにのみ採用することをお勧めします。機能と堅牢性の面で、大規模なシナリオや複雑度が高いシナリオをサポートする用途には適していません。

ここでは、バージョン管理のセットアップと使用に役立つ一般的な推奨事項をいくつか紹介します。

• アラート: 他のユーザーによる重要なファイルの追加、削除、変更操作が通知されるようにアラートを設定します。
• スコープ: リモート ストレージの場所に関して、スコープを明確に定義します。 リモートストレージの場所の最も望ましいスコープ設定は、利用者へのコンテンツ配信においてダウンストリームのワークスペースとアプリに適用されるのと同じスコープです。
• アクセス: リモート ストレージの場所に対するアクセス許可のセットアップには、デプロイ パイプラインのアクセス許可とワークスペース ロールに関するセットアップと同様のアクセス許可モデルを使用します。 コンテンツ作成者には、リモート ストレージの場所に対するアクセス許可が必要です。
• ドキュメント: リモート記憶域の場所にテキスト ファイルを追加し、そのリモート記憶域の場所、用途、所有権、アクセス、および定義されたプロセスの説明を記述します。

以降のセクションでは、それぞれのアプローチの概要と、採用するアプローチを決定する際の主な考慮事項について説明します。

SharePoint または OneDrive for Work and School を使用したバージョン管理

SharePoint にはファイルのバージョン管理機能が組み込まれています。 コンテンツ作成者はセマンティック モデルまたはレポートをローカル環境で開発でき、その変更内容は SharePoint または OneDrive for Work and School ドキュメント ライブラリに同期されます。

次の図は、SharePoint または OneDrive を使用してバージョン管理を実行する方法の概略を示しています。

この図は、以下のプロセスと構成要素を示しています。

品目	説明
	コンテンツ作成者は、ローカル環境でセマンティック モデルとレポートを開発し、それらのモデルとレポートを .pbix ファイルとして保存します。
	準備ができたら、コンテンツ作成者は変更を保存し、リモートの SharePoint または OneDrive for Work and School ライブラリに同期します。
	リモート ライブラリではコンテンツ作成者がファイル レベルの変更を追跡管理できるため、バージョン管理が容易です。
	コンテンツ作成者は、発行済みのセマンティック モデルまたはレポートを .pbix ファイルにリンクすることができ、容易に OneDrive の更新を行えます。 OneDrive の更新により、コンテンツの変更内容は 1 時間ごとに、自動的に発行されます。
	OneDrive の更新が完了した後、コンテンツ作成者は、Power BI コンテンツの変更内容が反映されたことを Fabric ワークスペースで確認できます。

要約すると、コンテンツ作成者は、SharePoint または OneDrive for Work and School ライブラリに格納した .pbix ファイルに、発行済みのセマンティック モデルまたはレポートをリンクすることができます。 このアプローチの場合、変更を反映するためにコンテンツ作成者がセマンティック モデルを発行する必要はなくなり、 1 時間ごとに行われる OneDrive の更新によって、変更が自動的に反映されます。 これは便利なアプローチですが、いくつか注意事項があるだけでなく、元に戻すことは容易ではありません。

SharePoint または OneDrive によるバージョン管理は、セットアップと管理が簡単である反面、多くの制約があります。 たとえば、変更内容をコンテンツの内部まで確認することはできず、バージョン間の比較もできません。 また、より複雑な変更管理プロセス (たとえば、この記事内で後述するブランチ化や pull request など) を設定することはできません。

SharePoint または OneDrive による変更管理は、以下のようなシナリオの場合に検討対象となります。

• コンテンツが、.pbix ファイルとして保存されたセマンティック モデルやレポートのみで構成されている場合。
• セルフサービスのユーザーがコンテンツの作成と管理を行う場合。
• Microsoft Teams を使用してコンテンツ作成者間の共同作業が行われる場合。
• コンテンツ作成者が Git とソース コントロール管理に慣れていない場合。
• コンテンツ作成者が単一のアイテムを扱い、複雑度や共同作業の必要性が小さい場合。
• .pbix ファイルに、内容の暗号化が必要な秘密度ラベルが適用される場合。

以下のようなシナリオの場合、SharePoint または OneDrive による変更管理は避けてください。

• コンテンツが、セマンティック モデルでもレポートでもないアイテム タイプで構成されている場合。
• コンテンツの複雑度が高い、または適用範囲が広い場合。
• 複数のコンテンツ作成者が共同作業を行い、同じアイテムを同時に作業対象とする必要がある場合。

以降のセクションでは、SharePoint または OneDrive と Power BI で効果的にバージョン管理を行うための追加の考慮事項について説明します。

Microsoft Teams 統合

Microsoft Teams でコンテンツ作成者間の共同作業を行う場合、Teams のドキュメント ライブラリを使用することがあります。 ドキュメント ライブラリは SharePoint サイト上で機能します。(別の SharePoint サイトや OneDrive フォルダーではなく) ドキュメント ライブラリを使用すると、コンテンツ、ファイル、共同作業を確実に一元管理することができます。

ファイルのチェックインとチェックアウト

変更の競合を避けるために、作業対象ファイルはチェックアウトすることが推奨されます。 チェックアウトされたファイルは、作業完了後、変更内容を説明するコメント付きでチェックインされます。 ファイルのチェックインとチェックアウトは、SharePoint または OneDrive for Work and School でのバージョン管理において、コンテンツ作成者間の共同作業の質を高めるのに役立ちます。 ファイルのチェックインとチェックアウトをしながら複数のコンテンツ作成者が作業する場合は、SharePoint サイトのライブラリに変更を加える際、直前の変更内容と、直前のチェックイン時に付けられたコメントを確認できます。

バージョンの履歴

SharePoint サイトのドキュメント ライブラリに予期しない稼働中断が発生した場合に備え、コンテンツを別の場所にバックアップしておくことは重要です。 また、SharePoint サイトに保持するバージョン数の制限を設定し、古いバージョンが削除されるようにしておくことが推奨されます。 そのようにすると、いつも有意義なバージョン履歴情報を参照でき、占有スペースが大きくなりすぎるのを防ぐこともできます。

さらに高度なバージョン管理が必要な場合は、リモート リポジトリ (Azure Repos など) にファイルを格納し、ソース管理によって変更管理を行う方法があります。

リモート Git リポジトリを使用したソース管理

リモート Git リポジトリは、ファイル ソース管理の利便性に優れており、コンテンツ作成者が変更管理を行う際の選択肢が豊富に用意されています。 簡単にいえば、コンテンツ作成者はローカル環境でも Power BI サービス内でもコンテンツを開発することができ、その変更内容を、コミット操作によってリモート Git リポジトリ (Azure Repos など) にプッシュすることができます。

次の図は、Azure Repos を使用してソース管理を実行する方法の概略を示しています。

この図は、以下のプロセスと構成要素を示しています。

品目	説明
	コンテンツ作成者は、セマンティック モデルとレポートをローカル環境で開発し、それらのモデルとレポートを .pbip ファイルとして保存します。 また、セマンティック モデルを開発してモデルのメタデータを保存することもできます。
	準備ができたら、コンテンツ作成者は変更を保存し、定期的にコミットしてリモート Git リポジトリにプッシュします。
	リモート Git リポジトリではコンテンツ作成者がオブジェクト レベルの変更を追跡管理できるため、バージョン管理が容易です。 また、ブランチを作成してコンテンツを操作し、そこでの変更内容を、pull request を使用して 1 つのブランチにマージすることもできます。
	コンテンツ作成者は、Git 統合を使用してリモート リポジトリからコンテンツを同期できます。 また、他のアプローチでコンテンツをデプロイすることもできます (たとえば、Azure Pipelines と REST API の併用など)。
	同期またはデプロイの完了後、コンテンツ作成者は、Power BI コンテンツの変更内容が反映されたことを Fabric ワークスペースで確認できます。 コンテンツ作成者は、データフローやノートブックなどのコンテンツをワークスペース内で作成できます。 Git 統合を使用する場合には、このワークスペースを、リモート リポジトリの特定のブランチにリンクします。
	コンテンツ作成者は、ワークスペースでの変更内容を、Git 統合を使用してリモート リポジトリにコミットおよびプッシュできます。 この変更では、ワークスペースで作成したサポート対象コンテンツ (データフローやノートブックなど) のアイテム定義をインポートできます。

要約すると、コンテンツ作成者は、集中管理された Azure Repos リモート リポジトリに .pbip ファイル、メタデータ ファイル、ドキュメントを格納できます。 このようなファイルは "技術所有者" によって管理されます。 コンテンツ作成者がソリューションを開発するのに対し、技術所有者はソリューションを管理し、変更点を確認し、1 つのソリューションにマージする作業を担当します。 Azure Repos には、変更管理に関して、SharePoint や OneDrive よりも高度なオプションが用意されています。 すべてのコンテンツとコラボレーションの基盤になるので、適切にキュレーションし、文書化したリポジトリを保守することが不可欠です。

ソース管理による変更管理は、以下のようなシナリオの場合に検討対象となります。

• 集中型または分散型のチームがコンテンツの作成と管理を行う場合。
• Azure DevOps を使用してコンテンツ作成者間の共同作業が行われる場合。
• コンテンツ作成者が Git、ソース コントロール管理、または DataOps の原則に慣れている場合。
• コンテンツ作成者が扱うコンテンツの複雑度または重要度が高いか、コンテンツの複雑度と重要度が増大する見込みである場合。

以下は、Azure DevOps で効果的にソース管理を行うための前提条件や考慮事項の一部です。

• Git: コンテンツ作成者が変更をコミットしてリモート リポジトリにプッシュするには、Git をダウンロードしてインストールする必要があります。 Git は、ファイルの変更を追跡する分散バージョン管理システムです。 Git の基本については、「Git とは」を参照してください。
• ツール: コンテンツ作成者が Git を使用するには、SCM (Visual Studio、Visual Studio Code など) 用のコマンド ライン インターフェイス (CLI) またはグラフィカル ユーザー インターフェイス (GUI) クライアントを使用する必要があります。
• ライセンスとアクセス許可: コンテンツ作成者が Azure Repos Git リポジトリを作成および使用するには、以下の条件を満たす必要があります。
  • アクセス レベルが "Basic" に設定されている ("利害関係者" ではない) こと。
  • 組織とプロジェクトに所属していること。
  • 適切なリポジトリ権限を持っていること。
• Fabric Git 統合: リモート リポジトリ内のコンテンツを Microsoft Fabric ワークスペースと同期する際、コンテンツ作成者は Fabric Git 統合を使用します。 このことは、Fabric ポータルで作成したコンテンツ (データフローなど) の変更管理を行うために重要です。

Azure Repos でソース管理を使用することの主な利点としては、コンテンツ作成者間の共同作業の質を高められること、コンテンツの変更とデプロイに関するカスタマイズと監視を強化できることが挙げられます。

次の図は、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 の統合を使用する場合、運用ワークスペースはどのブランチとも同期しません。

以降のセクションでは、Azure DevOps と Power BI で効果的にソース管理を行うための追加の考慮事項について説明します。

ブランチを使用する

コンテンツ作成者の共同作業を実現するには、ブランチ戦略を採用します。 分岐戦略を使うことで、個々のコンテンツ作成者が自分のローカル リポジトリで分離して作業できます。 準備ができたら、リモート リポジトリで 1 つのソリューションとして変更を結合することができます。 コンテンツ作成者は、特定の開発、改善、バグ修正の作業項目にリンクすることで、ブランチに作業のスコープを設定する必要があります。 各コンテンツ作成者は、リモート リポジトリに作業スコープに対応した独自のブランチを作成します。 ローカル ソリューション上での作業内容は、わかりやすい説明のコミット メッセージ付きでコミットされ、リモート リポジトリ内にあるブランチのバージョンの 1 つとしてプッシュされます。 コミット メッセージには、そのコミットで加えられた変更を記述します。

ブランチ戦略で Fabric コンテンツの管理を行うにあたっては、以下の要因について検討してください。

• コンテンツ作成者に自分の作業を行わせる際、どのブランチのクローンを作成するか。 たとえば、メイン ブランチのクローンで作業する場合 (トランク ベースの開発と呼ばれる) と、その他のブランチで作業する場合 (特定のリリース予定バージョンを含んだリリース ブランチのコンテンツなど) があります。
• リリース ブランチを使用し、スコープを特定のコンテンツ リリース向けに限定した作業を行うかどうか。
• Fabric Git 統合を使用する場合、どのブランチをどのワークスペースに接続するか。

変更をバッチにまとめてコミットする

コンテンツ開発を進める際は、小まめに段階を区切り、変更内容をバッチ (またはグループ) にまとめることをお勧めします。 グループ化するには、そのソリューションに関する個々の具体的な作業項目 (機能や問題など) に対応する変更内容をまとめます。 準備ができたら、コンテンツ作成者はそれらの段階的な変更をコミットします。

このように変更内容をグループ化することには、以下のような利点があります。

• 開発作業を構造化しやすくなります。コンテンツ作成者自身が変更内容をグループ単位でレビューし、文書化する機会が得られます。
• 計画時の方針と開発作業の方向性との調整や、機能間、問題間の関連付けがしやすくなって、作業の進捗状況を透過的に把握できます。
• 変更内容が適切にグループ化され、明確なコミット メッセージが記録されていると、技術担当者がコンテンツ作成者からの pull request をレビューしやすくなります。

Power BI コンテンツに対する変更内容の段階的なグループ化とコミットを行うにあたっては、以下の要因について検討してください。

• 変更内容のグループ化とコミットを、ローカル リポジトリから行うか、それとも Fabric ワークスペースから行うか。
• 複数のモデルやレポートを 1 つのリポジトリに格納する場合、.pbip ファイルは最上位フォルダーに配置することをお勧めします。 そうすると、変更内容の識別とグループ化がしやすくなります。
• メタデータ内の不要な変更点やメリットがない変更点については、gitignore ファイルまたは .gitattributes ファイルを使用して無視することができます。 これを利用すると、コミットするすべての変更内容が有意義なものになります。

変更をマージするための pull request を作成する

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

pull request を使用して変更内容を Power BI コンテンツにマージする際には、以下の要因について検討してください。

• レビューを実施するとき、どのような基準や慣行を適用するか (ある場合)。 たとえば、セマンティック モデルに関してはベスト プラクティス アナライザーのルールを適用できます。
• サードパーティ製ツールがないと読み取りや理解が困難なレポート メタデータについて、どのように変更内容のレビューを行うか。
• マージの競合に対してどのように対処し、解決するか。

チェックリスト - ファイルの保存場所について計画を立てる際の主な意思決定事項とアクションは以下のようなものです。

関連するコンテンツ

このシリーズの次の記事では、コンテンツ ライフサイクル管理の一部としてコンテンツ検証を行う方法について説明します。