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

注

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

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

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

ライフサイクル管理は、コンテンツの作成から最終的な提供終了までを処理するために使用するプロセスとプラクティスです。 ライフサイクル管理の最初の段階では、ソリューションの計画とライフサイクル管理へのアプローチに影響を与える主要な意思決定を行うコンテンツを計画および設計します。 第 2 段階では、コンテンツを開発し、変更を管理します。

コンテンツのライフサイクル中にコンテンツの変更を管理することは、コンテンツ作成者間の効果的なコラボレーションと、コンシューマーへのコンテンツの安定した一貫した配信を確保するために重要です。

次の図は、Power BI コンテンツのライフサイクルを示しています。ステージ 2 では、コンテンツを開発し、変更を管理します。

注

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

ヒント

この記事では、コンテンツの開発とそのライフサイクル全体にわたる変更の管理に役立つ主な決定事項と考慮事項について説明します。 コンテンツを開発し、変更を管理する方法の詳細については、次を参照してください。

• Microsoft Fabric のライフサイクル管理とは:この記事では、Fabric Git の統合とデプロイ パイプラインの技術的な概要と チュートリアル を提供します。
• ライフサイクル管理のベスト プラクティス: この記事には、Fabric と Power BI のライフサイクル管理機能を使用してコンテンツを開発し、変更を管理するための実用的なヒントとガイダンスが含まれています。
• Power BI Desktop OneDrive と SharePoint の統合: この記事では、.pbix ファイルを使用してバージョン管理を実行するときに、OneDrive for Work and School または SharePoint に保存されたファイルを使用して保存するオプションの概要について説明します。
• Azure Repos での Git の概要: この一連の記事には、Azure Repos の Git リポジトリを使用してソース管理を実行するための実用的なヒント、チュートリアル、ガイダンスが含まれています。

コンテンツ作成者と所有者は、 バージョン 管理を使用してコンテンツの変更を管理する必要があります。 バージョン管理は、中央リポジトリ内のファイルまたはコードに対する変更を管理する方法です。 このプラクティスにより、より効果的なコラボレーションとコンテンツ管理が容易になります。

バージョン管理のその他の利点には、次の機能があります。

• 複数のコンテンツ作成者からの変更をマージし、マージの競合を処理します。
• どのコンテンツが変更され、そのコンテンツで何が変更されたかを特定します。
• コンテンツの変更を特定の作業項目にリンクします。
• バージョン履歴を使用して、変更を個別のリリースにグループ化します。
• 変更またはコンテンツのバージョン全体をロールバックします。

ヒント

可能な場合は、作成するすべてのコンテンツにバージョン管理を使用することをお勧めします。 バージョン管理を使用すると、コンテンツ作成者とコンシューマーの両方にとって大きな利点が得られ、ファイルの損失や変更のロールバックができないことによる中断のリスクが軽減されます。

バージョン管理を設定する最初の手順は、コンテンツの開発方法を決定することです。

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

コンテンツの作成方法に応じて、コンテンツの管理方法についてさまざまな決定を行います。 たとえば、Power BI レポートとセマンティック モデルの場合、Power BI Desktop (.pbix) ファイルのバージョン管理のオプションは 、Power BI Desktop プロジェクト (.pbip) 形式と比較して少なくなります。 これは、.pbix ファイルがバイナリ形式であるのに対し、.pbip 形式にはテキストベースの人間が判読できるコンテンツとメタデータが含まれているためです。 人間が判読できるコンテンツとメタデータを使用すると、 ソース管理を使用してモデルの変更を簡単に追跡し、変更を報告できます。 ソース管理は、コンテンツ 内 の変更をコードとメタデータに対して表示および管理する場合です。

ヒント

Power BI Desktop を使用してセマンティック モデルとレポートを開発する場合は、.pbix ファイルではなく .pbip ファイルを使用することをお勧めします。 XMLA ツールを使用してセマンティック モデルを開発する場合は、.bim ファイルではなく、表形式モデル定義言語 (TMDL) 形式を使用することをお勧めします。 詳細については、この記事 で後述する「コンテンツの形式を決定する」を参照してください 。

Power BI Desktop (パワー BI デスクトップ)

Power BI Desktop を使用してセマンティック モデルまたはレポートを作成し、.pbix ファイルまたは .pbip ファイルとして保存できます。 Power BI Desktop を使用するときにも使用できる追加のカスタム コンテンツ ファイルがあります。 Power BI Desktop を使用してコンテンツを作成する場合は、次のような重要な決定を行う必要があります。

• 使用するファイル形式: .pbix ファイルまたは .pbip ファイルとしてコンテンツを保存できます。 詳細については、この記事 で後述する「コンテンツの形式を決定する」を参照してください 。
• カスタム コンテンツを管理する方法: テーマ、カスタム ビジュアル、またはイメージを Power BI Desktop ファイルに追加できます。ライフサイクル管理には個別の考慮事項が必要になる場合があります。 たとえば、コンテンツ作成者が独自のカスタム ビジュアルを作成する場合は、ビジュアル定義を別のファイルに保存して管理する必要があります。
• プレビュー機能を管理する方法: Power BI Desktop でプレビュー機能または設定をオプトインできます。これは、コンテンツとその使用方法を変更します。 たとえば、プレビュー機能を使用するコンテンツを検証するための追加の手順を実行できます。

Web 作成

データフロー、ダッシュボード、スコアカードなどの特定のコンテンツは、Fabric ポータルでのみ作成できます。 また、Fabric ポータルまたはローカル ツールの両方で、セマンティック モデル、レポート、ページ分割されたレポートなどの一部のコンテンツを作成または変更することもできます。 Web オーサリングを使用してコンテンツを作成する場合は、次のような重要な決定を行う必要があります。

• 変更を管理する方法: Web オーサリングを使用して多くのアイテムの種類に変更を加えることができますが、これらの変更は即座に保存され、以前のバージョンが上書きされる可能性があります。 たとえば、他のユーザーと共同作業を行う場合は、共有アイテムに対する Web 作成を避け、自分のコピーで作業する必要がある場合があります。
• コンテンツ バックアップを取得する方法: Web オーサリングを使用してレポートやセマンティック モデルなどのコンテンツを作成できますが、これらの項目を ローカルの .pbix ファイルにダウンロードすることはできません。 たとえば、メタデータを取得して格納することで、このコンテンツのバックアップを選択できます。

ヒント

データフローとスコアカードを開発するときは、項目定義を取得して変更を管理し、バックアップを保存することをお勧めします。 Fabric REST API を使用して、データフローとスコアカードの取得を自動化できます。 具体的には、 Get Dataflow エンドポイントと Get Scorecards エンドポイントをそれぞれ使用できます。

注意事項

ダッシュボードなどの一部のコンテンツには、定義を取得するオプションがありません。 このコンテンツでは、変更を簡単に追跡したり、バックアップを取得したりすることはできません。

その他のツール

他のツールを使用して、特定の種類のコンテンツを作成または管理できます。 これらのツールは、追加の利点を提供したり、ワークフローに適したり、特定の機能やコンテンツ タイプを管理する必要がある場合があります。 他の Microsoft ツールまたはサード パーティ製ツールの両方を使用して、コンテンツを作成および管理できます。 コンテンツの作成または管理に使用できるその他のツールは次のとおりです。

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

他のツールを使用してコンテンツを作成する場合は、次のような重要な決定を行う必要があります。

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

コンテンツの作成方法を決定したら、次に、保存および管理に使用する形式を選択する必要があります。

コンテンツの形式を決定する

作成するコンテンツと使用するツールによっては、コンテンツで異なるファイル形式が使用される場合があります。 ただし、ツール内であっても、異なる形式から選択する必要があります。 たとえば、Power BI Desktop で作成するレポートやセマンティック モデルの場合は、.pbix ファイルと .pbip ファイルのどちらかを選択する必要があります。 この決定は、コンテンツの開発方法だけでなく、そのライフサイクル中にそのコンテンツを管理する方法、および特定の開発タスクをどれだけ効率的に完了できるかにも機能的な影響を与えます。 たとえば、Power BI Desktop でコンテンツを開発し、Git 統合を使用してそのコンテンツを発行する場合は、.pbip ファイルを使用する必要があります。

コンテンツのファイル形式は、そのライフサイクル中に変更される可能性があります。 たとえば、最初にレポートやモデル用の .pbix ファイルの作成を開始できます。 ただし、新しいコンテンツ作成者が共同作業を行いたい場合や、生産性を向上させる場合は、.pbip ファイルなどの別の形式に切り替えることができます。

次のセクションでは、Power BI で選択する必要がある一般的な形式の概要について説明します。

Power BI Desktop (.pbix) ファイル形式

Power BI レポートとモデルの既定の最も一般的な形式は、.pbix ファイル形式です。 このバイナリ形式は、ほとんどの人にとって管理と使用が簡単です。 ただし、ファイルの内容を開いたり使用して変更を追跡したり、開発者の生産性を向上させたりすることはできません。

次の場合は、.pbix ファイル形式を使用します。

• OneDrive の更新を使用してコンテンツを公開する予定です。
• コンテンツ作成者は、複数のファイルのフォルダー (.pbip 形式など) ではなく、1 つのファイルを使用して共有したいと考えています。
• コンテンツ作成者は.pbix形式を好みます。

Power BI Projects (.pbip) ファイル形式

.pbix ファイルの代わりに、 Power BI Projects (.pbip) 形式を使用してコンテンツを保存することもできます。 この形式では、ファイルが フォルダー構造に分割されます。 .pbip のフォルダー構造には、モデルとレポートの定義と構成を提供する複数のメタデータ ファイルを開いて読み取ることができます。 ファイルの内容を開いて読み取ることができるため、手動またはプログラムを使用して変更を加えることができるため、生産性が大幅に向上する可能性があります。 Git 統合などの Fabric の一部の機能では、Power BI Desktop でコンテンツを開発する場合は、.pbix 形式ではなく .pbip 形式を使用する必要もあります。

次の図は、.pbix ファイルと .pbip ファイルの違いを示しています。

要約すると、ユーザーまたは自動化されたプロセスは、.pbip ファイルの内容を Power BI Desktop で開かずに表示および変更できます。 これに対し、.pbix ファイルはバイナリ ファイルであり、その内容を表示または変更するためのメソッドはサポートされていません。 これらのメタデータの内容を表示または変更できるようにするさまざまなシナリオがあります。次に例を示します。

• 変更を追跡して管理し、変更内容を可視化することで、ソース管理を行いたいと考えています。
• 変更を一括で行うか、ファイル内の何かを検索します。
• ビジュアル、テーブル、メジャーなど、ファイルの要素を再利用する必要があります。
• Power BI Desktop のユーザー インターフェイスに表示されないプロパティまたは設定を表示する場合。
• コンテンツを公開する前にメタデータをスキャンしてベスト プラクティス違反を探すなど、特定のプロセスを自動化する必要があります。

.pbip ファイル形式では、セマンティック モデルとレポート定義に それぞれ TMDL または PBIR 形式を使用することもできます。この形式には、留意すべき独自の利点と考慮事項があります。

次の場合は、.pbip ファイル形式を使用します。

• コンテンツの発行や展開には、OneDrive の更新ではなく、Git 統合を使用する予定です。
• ソース管理を使用して変更を追跡および管理する予定です。
• Power BI Desktop を他のツールと組み合わせて使用して、モデルやレポートを開発する予定です。
• 複数のコンテンツ作成者がモデルまたはレポートで共同作業を行います。
• 生産性の向上の恩恵を受け、モデルやレポートを作成する時間を節約したいと考えています。
• 開発、テスト、またはデプロイ プロセスの一部を自動化する予定です。
• モデルとレポート ファイルを、複数のレポートを含む .Report フォルダーや、複数のモデルを含む .SemanticModel フォルダーなど、さまざまな方法で構成したい場合があります。

ヒント

コンテンツを開発するときは、繰り返し実行するタスクなど、時間を無駄にしていると感じるシナリオを自己認識する必要があります。 これらのシナリオでは、多くの場合、Visual Studio Code、Fabric のノートブックなどの他のツールと共にこれらの新しい形式を利用することで、時間を節約できます。

テーブル モデル定義言語 (.tmdl) ファイル形式

モデルを .pbip として保存する場合は、テーブル モデル スクリプト言語 (TMSL) を使用する単一の .bim ファイルとして保存するか、新しいテーブル モデル定義言語を使用する複数の .tmdl ファイルのフォルダー構造に保存するかを選択できます。 TMDL は、セマンティック モデル定義に YAML に似た構文を使用します。これにより、モデルの変更を読み取って管理しやすくなります。

TMDL 形式の例を次に示します。

新しい TMDL 形式の利点は次のとおりです。

• モデル メタデータは簡潔で構造化され、読みやすくなるため、ソース管理と Git 統合をより適切に使用できます。
• 競合を作成することなく、変更をより簡単にマージできます。
• モデル間でのモデル オブジェクトの再利用やコピー (日付テーブルなど) など、特定のレポート タスクの効率を向上させることができます。

TMDL 形式のソース管理の例を次に示します。

TMDL 形式は、次の場合に使用します。

• ソース管理を使用して変更を追跡および管理する予定です。
• メタデータを変更することで、開発者の生産性を高めたいと考えています。
• セマンティック モデルは、Visual Studio Code や表形式エディターなどの他のツールを使用して開発します。

注

TMDL 形式は、 Power BI Desktop の TMDL ビューとは異なります。

• TMDL は、セマンティック モデルの言語とメタデータの形式です。
• TMDL ビュー は、モデルをプログラムで変更するための Power BI Desktop のスクリプト インターフェイスです。 TMDL スクリプトには、TMDL フォーマット ファイルと同様の YAML に似た構文が使用されます。 TMDL ビューの利点を得るために TMDL 形式を使用する必要はありません。

Power BI 拡張レポート (PBIR) 形式。

コンテンツを .pbip ファイルとして保存する場合は、既定のレポート形式または 新しい PBIR 形式を使用できます。 この新しい形式は、開発者の生産性とコラボレーションを強化できるいくつかの利点を提示します。特に、PBIR 形式を .pbip ファイルで使用する場合です。

PBIR 形式の例を次に示します。

PBIR 形式を使用する利点は次のとおりです。

• レポート メタデータは簡潔で構造化され、読みやすくなるため、ソース管理と Git 統合をより適切に使用できます。
• 次のような特定のレポート タスクの効率を向上させることができます。
  • visual.jsonをコピーして、ページ間でビジュアルを再利用またはコピーします。
  • レポート間でページを再利用またはコピーする。
  • ユーザー設定の色、フィールド、およびその他のビジュアル構成を一度に検索して置き換えます。
  • テーブル間で名前が変更または移動されたフィールドを含む "壊れた" ビジュアルを修正しました。
• メタデータ注釈をレポート メタデータに追加して、継続的インテグレーション/継続的配置 (CI/CD) をサポートする特定の自動化またはタスクを容易にすることができます。
• 新しい PBIR 形式でより多くのユーティリティを持つ セマンティック リンク ラボ などのツールを利用できます。

PBIR 形式は、次の場合に使用します。

• ソース管理を使用して変更を追跡および管理する予定です。
• メタデータを変更することで、レポート作成者の生産性を高めたいと考えています。
• レポートをプログラムまたは自動で変更する場合。

注意事項

PBIR 形式を使用する前に、まず 制限事項と考慮事項 を確認してください。 これらの制限事項と考慮事項は時間の経過と共に変化するため、Power BI コンテンツの特定の要件を満たさなくなる特定の項目があるかどうかを定期的に確認してください。

さらに、形式に関係なく、すべてのレポート メタデータにデータ ポイントが含まれる可能性があります。 詳細については、「 PBIR フォルダーとファイル」を参照してください。

Power BI テンプレート (.pbit) ファイル形式

Power BI レポートまたはセマンティック モデルを .pbit ファイルとして保存することもできます。 ただし、.pbit ファイルは、特定のレポート レイアウトまたはモデル構造を再利用することを目的としています。 開発時に Power BI コンテンツを保存および管理するには、.pbit 形式を使用しないでください。 代わりに、組織内の他のユーザーと共有する再利用可能なテンプレートを作成する場合は、.pbit ファイルを使用する必要があります。

その他の形式

Power BI で他のコンテンツ (ダッシュボード、データフロー、ページ分割されたレポートなど) を開発する場合、Fabric でアイテムを開発する場合、コンテンツ ファイルがない可能性があります。 または、項目の定義のみをソース管理に保存することもできます。 詳細については、このシリーズの前の記事で ファイルを格納する場所を決定する を参照してください。

ワークスペースを設定して使用する方法を決定する

コンテンツを開発するときは、複数のワークスペース (またはステージ) を使用して、組織で使用される実稼働コンテンツと、開発または検証されるコンテンツを分離する必要があります。 コンテンツに個別のワークスペースを使用するには、いくつかの利点があります。

• 現在使用中のコンテンツに影響を与えることなく、コンテンツを開発およびテストできます。 これにより、運用環境のコンテンツに意図しない中断を引き起こす可能性のある変更を回避できます。
• 個別の データ ゲートウェイ や Fabric 容量の使用など、コンテンツの開発とテストには個別のリソースを使用できます。 これにより、開発とテストに使用されるリソースによって運用ワークロードが中断され、データの更新やレポートが遅くなるのを回避できます。
• これらのステージごとに個別の環境を用意することで、コンテンツを開発、テスト、リリースするためのより構造化されたプロセスを作成できます。 これにより、生産性の向上に役立ちます。

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

Von Bedeutung

個別の環境を使用することは、コンテンツ ライフサイクル管理アプローチを確実に成功させるための重要な手順です。

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

このコンテンツのライフサイクル全体にわたって個別のワークスペースを使用する方法を計画するときは、次の質問に答えてください。

• 必要なワークスペースの数はいくつですか?
• アイテムの種類ごとにワークスペースを分離しますか?
• 各ワークスペースにアクセスできるユーザー
• ワークスペースは Fabric デプロイ パイプラインに属しますか。それとも、 Azure Pipelines を使用するなど、他の方法を使用してデプロイを調整しますか?
• ワークスペース間の発行をどのように管理しますか？ たとえば、レポートのテスト ワークスペース内のレポートが、データ 項目用の別のテスト ワークスペース内のセマンティック モデルに接続されるようにする必要がありますか。
• また、 別のオンプレミス データ ゲートウェイ クラスターなど、運用ワークスペース内の項目に個別のサポート リソースを使用する必要がありますか?

次のセクションでは、ライフサイクル管理を容易にするためにワークスペースを分離するために実行できるさまざまな方法の概要について説明します。

注

次のセクションでは、個別のワークスペースを設定して使用する方法について説明します。 次の 4 つの方法のいずれかを使用して、これらのワークスペースにコンテンツを展開できます。

• Power BI Desktop からの発行。
• Fabric デプロイ パイプラインを使用して別のワークスペースからコンテンツをデプロイする。
• Git 統合を使用してリモート Git リポジトリからコンテンツを同期する。
• Fabric REST API、Power BI REST API、または XMLA エンドポイントを使用してプログラムでコンテンツをデプロイする。

コンテンツを展開するためのこれらの方法の詳細については、「 ステージ 4: このシリーズの後半でコンテンツを展開する」を参照してください。

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

組織にとって重要ではないよりシンプルなコンテンツを配信する場合、多くの場合、2 つのワークスペースで十分です。 このシナリオでは、通常、コンテンツ作成者は同じアイテムに対して限られたコラボレーションを行い、コンテンツをローカルで開発します。

次の図は、テストワークスペースと運用ワークスペースのみで個別の環境を使用する方法の概要例を示しています。

この図は、このアプローチでワークスペースを分離するための次のプロセスとコンポーネントを示しています。

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

注

個別のワークスペースを設定して使用し、これらのワークスペース間でコンテンツを展開するには、さまざまな方法があります。 ただし、ローカル開発を実行せず、コンテンツを運用ワークスペースに直接発行することをお勧めします。 これにより、中断やエラーが防止される可能性があります。

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

ビジネスクリティカルなコンテンツを配信するときは、通常、3 つ以上の個別のワークスペースを使用します。 このシナリオでは、コンテンツ作成者は、多くの場合、ソリューションの最新バージョンを含む追加の開発ワークスペースで共同作業を行います。

次の図は、開発、テスト、運用の各ワークスペースで個別の環境を使用する方法の概要を示しています。

この図は、このアプローチでワークスペースを分離するための次のプロセスとコンポーネントを示しています。

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

注

デプロイ パイプラインでは、最大 10 個の異なる環境を使用できます。 たとえば、テストと運用の間に、パフォーマンス テストなどの特殊な種類の検証専用の実稼働前環境が必要な場合があります。

Git 統合を使用したプライベート ワークスペース

ビジネスクリティカルなコンテンツを配信する場合、各開発者は独自の プライベート ワークスペースを開発に使用することもできます。 このシナリオでは、プライベート ワークスペースを使用すると、コンテンツ作成者は Fabric ポータルでコンテンツをテストしたり、スケジュールされた更新などの機能を使用したりでき、開発チームの他のユーザーに中断が発生するリスクはありません。 コンテンツ作成者は、データフローなど、ここで Fabric ポータルでコンテンツを開発することもできます。 プライベート ワークスペースは、Azure DevOps と共に Git 統合を使用してコンテンツの変更を管理する場合に適しています。

注

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

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

次の図は、Git 統合でプライベート ワークスペースを使用して個別の環境を使用する方法の大まかな例を示しています。

注

この図は、変更をメイン ブランチにマージする前に、ソリューション (ブランチ 1 とブランチ 2) の個別のブランチで作業する個別の開発者を示しています。 これは、開発者が自分の変更をリモート Git リポジトリと統合し、Fabric での Git 統合のメリットを得る方法を示す Git ブランチ戦略 を簡略化した図です。

この図は、このアプローチでワークスペースを分離するための次のプロセスとコンポーネントを示しています。

アイテム	説明
	各コンテンツ作成者は、独自のローカル環境でコンテンツを開発します。
	準備ができたら、コンテンツ作成者は変更をコミットして、Azure Repos Git リポジトリなどのリモート リポジトリにプッシュします。
	リモート Git リポジトリでは、コンテンツ作成者はソース管理を使用してコンテンツの変更を追跡および管理し、コンテンツをブランチとマージしてコラボレーションを容易にします。
	コンテンツ作成者は、リモート リポジトリのブランチをプライベート ワークスペースと同期します。 同期後、作成者がブランチにコミットしてプッシュした最新の変更が、そのプライベート ワークスペースに表示されます。 異なるコンテンツ作成者は、変更を加える際に個別のブランチで作業します。
	プライベート ワークスペースでは、コンテンツ作成者は Web オーサリングを使用してコンテンツを開発し、独自の変更を検証できます。 Web オーサリングによって行われたコンテンツに対する変更は、コンテンツ作成者がワークスペースからこれらの変更をコミットしてプッシュするときに、Git リポジトリ内のブランチと同期できます。 異なるコンテンツ作成者は、独自の個別のプライベート ワークスペースで作業します。
	準備ができたら、コンテンツ作成者はプル要求を実行して、変更をソリューションのメイン ブランチにマージします。
	変更をマージすると、メイン ブランチは開発ワークスペースと同期されます。
	開発ワークスペースでは、コンテンツ作成者は、ダッシュボードなどの Fabric Git 統合でサポートされていないコンテンツを開発できます。 コンテンツ作成者は、最新のすべての変更を含む統合ソリューションも検証します。
	準備ができたら、コンテンツ作成者はコンテンツをテスト ワークスペースにデプロイします。 テスト ワークスペースでは、ユーザーはコンテンツのユーザー受け入れテストを実行します。
	準備ができたら、コンテンツ作成者はコンテンツを運用ワークスペースにデプロイします。 運用ワークスペースでは、コンテンツ作成者は、Power BI アプリを発行するか、ワークスペースからコンテンツを共有することでコンテンツを配布します。

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

個別の環境を使用する場合は、これらの環境で使用するさまざまなサポート リソースにこれがどのように影響するかも考慮する必要があります。 これらのサポート リソースについては、それらを同じ数のステージに分割する必要があるかどうか、またはこれらの環境全体でそれらの使用を調整する方法を検討してください。

• ゲートウェイ: 運用環境のワークロード には、個別のオンプレミス データ ゲートウェイ クラスター と VNet ゲートウェイを使用することを検討してください。 これは、中断を防ぐだけでなく、これらのゲートウェイを更新する必要がある場合のアップタイムを確保するのにも役立ちます。
• アプリ: テスト ワークスペースと運用ワークスペース用に個別のアプリを用意することを検討してください。 ステージ間でアプリをデプロイまたはコピーすることはできません。 テスト ワークスペース内のアプリは、運用環境ワークスペースに変更をデプロイする前にコンテンツとアプリ エクスペリエンスをテストするのに役立ちます。 運用ワークスペース内のアプリは、構造化されたエクスペリエンスでエンド ユーザーにコンテンツを配信することを目的としています。
• Azure DevOps: Azure DevOps を使用してソース管理とデプロイの共同作業と調整を行う場合は、ブランチと Azure Pipelines を使用してこれらの環境間でコンテンツをデプロイする方法を検討してください。 Azure Pipelines を使用してコンテンツをデプロイする方法の詳細については、「 ステージ 4: コンテンツのデプロイ」を参照してください。

ワークスペースの設定方法と使用方法を決定したら、次の手順は、コンテンツの変更を追跡および管理するためにバージョン管理を実行する方法を決定することです。

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

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

バージョン管理の設定と使用に役立つ一般的な考慮事項を次に示します。

• アラート: 他のユーザーが重要なファイルを追加、削除、または変更するときのアラートを設定する必要があります。
• スコープ: リモート ストレージの場所のスコープを明確に定義します。 リモート ストレージの場所のスコープは、コンシューマーにコンテンツを配信するために使用するダウンストリーム ワークスペースとアプリのスコープと同じであることが理想的です。
• アクセス: デプロイ パイプラインのアクセス許可とワークスペース ロールに対して設定したのと同様のアクセス許可モデルを使用して、リモート ストレージの場所へのアクセスを設定する必要があります。 コンテンツ作成者は、リモート ストレージの場所にアクセスする必要があります。
• ドキュメント: リモート ストレージの場所にテキスト ファイルを追加して、リモート ストレージの場所とその目的、所有権、アクセス、および定義されたプロセスについて説明します。

次のセクションでは、使用する方法と主な考慮事項について説明します。

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

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

ヒント

SharePoint または OneDrive は、 セルフサービス コンテンツの発行など、よりシンプルで小規模なシナリオでのバージョン管理にのみ使用します。 大規模または複雑なシナリオでは、 リモート Git リポジトリを使用してソース管理を実行することを検討する必要があります。

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

この図では、次のプロセスとコンポーネントについて説明します。

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

Von Bedeutung

バージョン管理は、セマンティック モデルまたはレポートを含む SharePoint または OneDrive for Power BI Desktop ファイルを使用してのみ実行できます。 SharePoint または OneDrive を使用して、データフローなどの他の Power BI 項目の種類や、ノートブックなどの Fabric アイテムの種類に対してバージョン管理を簡単に実行することはできません。 これらの他の項目の種類については、Azure Repos などのリモート Git リポジトリを使用してバージョン管理を実行する必要があります。

要約すると、コンテンツ作成者は、発行されたセマンティック モデルまたはレポートを、SharePoint または OneDrive for Work and School ライブラリに格納されている .pbix ファイルに リンク できます。 この方法では、コンテンツ作成者はセマンティック モデルを発行して変更を確認する必要がなくなりました。 代わりに、 OneDrive の自動更新後に変更が表示されます。この更新は 1 時間ごとに行われます。 便利ですが、このアプローチにはいくつかの 考慮事項が含まれており、簡単に元に戻すことはできません。

セットアップと管理は簡単ですが、SharePoint または OneDrive を使用したバージョン管理には、より多くの制限があります。 たとえば、コンテンツ 内 の変更を表示することはできず、バージョンを比較することもできません。 さらに、これらの変更を管理するためのより高度なプロセスを設定することはできません ( この記事で後述する分岐要求やプル要求など)。

SharePoint または OneDrive を使用して、次のシナリオでの変更を追跡および管理することを検討してください。

• コンテンツは、セマンティック モデルまたは .pbix ファイルとして保存されたレポートのみで構成されます。
• セルフサービス ユーザーがコンテンツを作成して管理します。
• コンテンツ作成者は、Microsoft Teamsを使用して共同作業を行います。
• コンテンツ作成者は、Git とソース管理の管理に慣れ親しんではいがありません。
• コンテンツ作成者は、複雑さとコラボレーションが制限された 1 つのアイテムを管理します。
• .pbix ファイルには、その内容を暗号化する秘密度ラベルが適用されています。

注

OneDrive と SharePoint では、一部の 制限付きシナリオを除き、秘密度ラベルが適用されたコンテンツがサポートされます。 これに対し、Fabric Git 統合 では秘密度ラベルはサポートされていません。

SharePoint または OneDrive を使用して、次のシナリオでの変更を追跡および管理しないようにします。

• コンテンツは、セマンティック モデルやレポート以外のアイテムの種類で構成されます。
• コンテンツが複雑であるか、スコープが大きい。
• コンテンツ作成者は、同じアイテムに対して同時に共同作業を行う必要があります。

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

Microsoft Teams 統合

コンテンツ作成者がコラボレーションにドキュメント ライブラリを使用する場合は、Microsoft Teamsのドキュメント ライブラリを使用できます。 ドキュメント ライブラリは SharePoint サイトであり、ドキュメント ライブラリ (別の SharePoint サイトまたは OneDrive フォルダーではなく) を使用すると、コンテンツ、ファイル、コラボレーションの一元化が保証されます。

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

変更の競合の可能性を回避するために、作業中のファイルを チェックアウト する必要があります。 変更が完了したら、変更を説明するコメントを含むファイルをチェックインします。 ファイルのチェックインとチェックアウトは、SharePoint または OneDrive for Work and School をバージョン管理に使用する場合に、コンテンツ作成者間のコラボレーションを向上させるために役立ちます。 複数のコンテンツ作成者がファイルをチェックインおよびチェックアウトする場合は、SharePoint サイト ライブラリを変更して、最後の更新プログラムと最後のチェックインのコメントを表示できます。

バージョン履歴

SharePoint サイト ドキュメント ライブラリが予期せず中断された場合に備えて、コンテンツを別の場所にバックアップしてください。 また、SharePoint サイトに保持されているバージョンの数に制限を設定し、古いバージョンを削除する必要があります。 これにより、バージョン履歴が意味を持ち続け、領域を占有しすぎないようにします。

より高度なバージョン管理のために、Azure Repos などのリモート リポジトリにファイルを格納し、ソース管理を使用して変更を管理できます。

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

リモート Git リポジトリを使用すると、ファイルのソース管理が容易になり、コンテンツ作成者は変更を追跡および管理するためのより多くのオプションを使用できます。 簡単に言うと、コンテンツ作成者は、ローカルまたは Power BI サービスでコンテンツを開発し、それらの変更をコミットして、Azure Repos や GitHub などのリモート Git リポジトリにプッシュできます。

注

Git 統合を使用せずにコンテンツのソース管理を実行することもできます。 このシナリオでは、リモート Git リポジトリでコンテンツの変更を追跡および管理しますが、REST API または XMLA 読み取り/書き込みエンドポイントを使用してコンテンツをデプロイします。 これらのコンテンツ展開方法の詳細については、「 ステージ 4: コンテンツの展開」を参照してください。

次の図は、コンテンツをローカルで開発し、リモート リポジトリに変更をコミットしてソース管理を実行する方法の概要を示しています。リモート リポジトリは、Git 統合を使用して Fabric ワークスペースと同期できます。

この図では、次のプロセスとコンポーネントについて説明します。

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

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

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

• 集中型または分散型のチームがコンテンツの作成と管理を行う場合。
• Azure DevOps を使用してコンテンツ作成者間の共同作業が行われる場合。
• コンテンツ作成者は、Git、ソース管理、または DataOps の原則に精通しています。
• コンテンツ作成者は、複雑なコンテンツや重要なコンテンツを管理したり、コンテンツの規模を拡大したり、複雑さと重要性を増したりすることを期待します。

Azure DevOps でソース管理を効果的に使用するのに役立つ前提条件と考慮事項を次に示します。

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

ヒント

ローカル開発でソース管理を容易にするには、 Visual Studio Code などのクライアント アプリケーションを使用することをお勧めします。 Power BI Desktop を使用してコンテンツを開発した後、Visual Studio Code を使用して、変更をステージング、コミット、およびリモート リポジトリにプッシュすることで、そのコンテンツのソース管理を実行できます。

Warnung

Fabric Git の統合には、サポートされている項目とシナリオ に関するいくつかの制限 があります。 最初に、Fabric Git 統合が特定のシナリオに最も適しているかどうか、またはソース管理を実装するために別のアプローチを取る必要があるかどうかを確認します。

さらに、 Fabric Git 統合では秘密度ラベルはサポートされておらず、 秘密度ラベルを含む項目のエクスポートが無効になっている可能性があります。 コンテンツに秘密度ラベルがある場合は、データ損失防止ポリシーを引き続き受け入れながら、バージョン管理を実現する方法を計画する必要があります。

Azure Repos または GitHub でソース管理を使用する主な利点は、コンテンツ作成者間のコラボレーションの向上と、コンテンツの変更とデプロイに関するカスタマイズと監視の強化です。

次の図は、Azure DevOps がソース管理とのコラボレーションを可能にする方法の概要を示しています。 AzureDevOps の代わりに GitHub Enterprise を使用することもできます。これには、同様の機能を実行するさまざまなサービスが含まれます。

注

前の図は、Azure DevOps を使用して共同作業を行う方法の 1 つの例を示しています。 ニーズとチームの働き方に最も適したアプローチを選択します。

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

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

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

Von Bedeutung

Power BI コンテンツのライフサイクルを管理する場合、ソース管理の利点を最大限に活用するには、分岐、コミット、プル要求、マージの効果的な使用が不可欠です。

ブランチを使用する

コンテンツ作成者は、 ブランチ戦略を使用してコラボレーションを実現します。 ブランチ戦略を使用すると、個々のコンテンツ作成者がローカル リポジトリで分離して作業できます。 準備ができたら、リモート リポジトリで変更を 1 つのソリューションとして組み合わせます。 コンテンツ作成者は、特定の開発、改善、バグ修正のために作業項目にリンクすることで、作業の範囲をブランチに限定する必要があります。 各コンテンツ作成者は、作業範囲のリモート リポジトリの独自のブランチを作成します。 ローカル ソリューションで行われた作業はコミットされ、リモート リポジトリ内のブランチのバージョンにプッシュされ、わかりやすい コミット メッセージが表示されます。 コミット メッセージは、そのコミットで行われた変更を示します。

ブランチ戦略を使用して Fabric コンテンツを管理する場合は、次の要因を考慮してください。

• コンテンツ作成者は独自の作業のためにどのブランチを複製するべきか。 たとえば、これらのブランチがメイン ブランチ ( トランク ベースの開発と呼ばれます) の複製である場合や、コンテンツの特定の計画バージョンのリリース ブランチなど、他のブランチである場合などです。
• リリース ブランチを使用して、特定の作業を個別のコンテンツ リリースに限定するかどうか。
• Fabric Git 統合を使用する場合、どのブランチがどのワークスペースに接続するか。

ヒント

コラボレーション を効果的に促進するためにブランチ戦略を 最適に使用する方法に関する具体的なガイダンスと推奨事項については、Git 分岐戦略の採用に関する説明を参照してください。

コミットにおけるバッチ変更

コンテンツを開発する際、作成者は定期的に変更をバッチ (またはグループ) にステージングする必要があります。 これらの変更は、ソリューションの特定の作業項目 (機能や問題など) に対処する必要があります。 準備ができたら、コンテンツ作成者はこれらの段階的な変更をコミットします。

このように変更をバッチ処理すると、いくつかの利点があります。

• これは、開発の構造を構築するのに役立ち、コンテンツ作成者がグループ化した変更を確認して文書化する機会を提供します。
• 計画と開発の連携が向上し、機能や問題をリンクしやすくなり、作業の進め方に関する透明性を得ることができます。
• 技術的な所有者は、変更が適切にバッチ処理され、明確なコミット メッセージがある場合に、コンテンツ作成者からのプル要求をより簡単に確認できます。

Power BI コンテンツの変更をステージングしてコミットする場合は、次の要因を考慮してください。

• ローカル リポジトリまたは Fabric ワークスペースから変更をステージングしてコミットするかどうか。
• 複数のモデルまたはレポートを 1 つのリポジトリに格納する場合は、最上位フォルダーに .pbip ファイルを配置します。 これにより、行った変更の識別とグループ化が容易になります。
• gitignore ファイルまたは .gitattributes ファイルを使用して、無害または役に立たないメタデータの変更を無視します。 これにより、コミットするすべての変更が意味を持つようになります。

ヒント

作業をステージングして Git リポジトリに コミットする 方法に関する具体的なガイダンスと推奨事項については、「コミットを使用して作業を保存する」を参照してください。

変更をマージするプル要求を作成する

変更をマージするために、コンテンツ作成者が プル要求を開きます。 pull request はピア レビューの申請であり、1 つのソリューションに完了した作業がマージされる可能性があります。 マージすると競合が発生する可能性があります。これは、ブランチをマージする前に解決する必要があります。 プル要求レビューは、作成者が開発、品質、コンプライアンスに関する組織の標準とプラクティスに準拠していることを確認するために重要です。

プル要求を使用して Power BI コンテンツへの変更をマージする場合は、次の要因を考慮してください。

• レビューを実行するために使用する標準とプラクティス (ある場合)。 たとえば、セマンティック モデルには ベスト プラクティス アナライザー のルールを使用できます。
• レポート メタデータに対する変更を確認する方法。サード パーティ製のツールを使用せずに読んで理解するのは簡単ではありません。
• マージの競合に 対処して解決する方法。

ヒント

プルリクエストを活用してコンテンツの変更をマージし、コラボレーションを円滑に進める方法に関する具体的なガイドラインと推奨事項については、「プルリクエストおよびマージ戦略とスカッシュマージ」を参照してください。

チェックリスト - ファイルを格納する場所を計画する場合、主な決定事項とアクションは次のとおりです。

• 開発ツールを選択する: コンテンツを開発するアプローチが、他のコンテンツ作成者と共同作業を行い、バージョン管理を使用する方法と一致していることを確認します。
• モデルとレポートの .pbip 形式と .pbix 形式のどちらかを選択します。通常、.pbip 形式はソース管理に役立ちますが、セルフサービス ユーザーは .pbix ファイルを使いやすく見つけることができます。
• セマンティック モデルとレポートの開発を分離する: バージョン管理は、異なるアイテムの種類の変更を個別に管理する場合に最も効果的です。 モデルとレポートの開発を分離 することをお勧めします。
• 必要なワークスペースの数を決定する: 個別の環境を使用することは、コンテンツ ライフサイクル管理を成功させるための重要な作業です。 必要なワークスペースの数が明確になっていることを確認し、適切な ワークスペース レベルの計画を実行します。
• バージョン管理を実装する方法を決定する: SharePoint または OneDrive for Business を使用するか、Azure DevOps を使用してソース管理を容易にすることで、より簡単なアプローチを決定します。
• リモート リポジトリを設定する: OneDrive フォルダーまたは Git Repo に構造化されたスペースを作成します。このリポジトリには、変更を追跡および管理するためのコンテンツを格納します。
• ソース管理を使用している場合は、.gitignore ファイルと .gitattributes ファイルを設定します。意味のある変更のみを追跡するようにリポジトリを設定してください。
• ソース管理を使用している場合は、分岐戦略とマージ戦略を定義します。ソース管理を設定し、ソース管理を使用して開発を最適にサポートする方法の明確なプロセスを必ず定義してください。 プロセスが過度に複雑にならないようにします。 代わりに、開発チームでの現在の作業方法を補完してみてください。

関連コンテンツ

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