このチュートリアルでは、データをワークスペースに読み込み、デプロイ パイプラインを Git 統合と共に使用し、開発、テスト、データとレポートの公開を他のユーザーと共同作業で行うプロセスのすべてを説明します。
注記
一部の Git 統合項目はプレビュー段階です。 詳細については、 サポートされている項目の一覧を参照してください。
前提条件
Git を Microsoft Fabric ワークスペースに統合するには、Fabric と Git の両方に対して次の前提条件を設定する必要があります。
ファブリックの前提条件
Git 統合機能にアクセスするには、 Fabric 容量が必要です。 サポートされているすべての Fabric 項目を使用するには、Fabric 容量が必要です。 まだお持ちでない場合は、 無料試用版にサインアップしてください。 既に Power BI Premium 容量を持っているお客様は、その容量を使用できますが、特定の Power BI SKU では Power BI 項目のみがサポートされることに注意してください。
さらに、管理ポータルから次の テナント スイッチ を有効にする必要があります。
- ユーザーは Fabric アイテムを作成できます
- ユーザーは、ワークスペース項目を自分の Git リポジトリと同期できます
- ワークスペースを作成する (新しいワークスペースに分岐する場合のみ)。
- ユーザーは、ワークスペース項目を GitHub リポジトリと同期できます:GitHub ユーザーのみ
これらのスイッチは、 組織の設定に応じて、テナント管理者、容量管理者、またはワークスペース管理者によって有効にすることができます。
Git の前提条件
現在、Git 統合は Azure DevOps と GitHub でサポートされています。 Fabric ワークスペースと Git 統合を使用するには、Azure DevOps または GitHub で次のものが必要です。
- 同じ Fabric ユーザーに登録されているアクティブな Azure DevOps アカウント (Azure DevOps 組織が Fabric テナントとは異なるテナントに存在する場合でもサポートされます)。 無料アカウントを作成します。
- 既存のリポジトリへのアクセス。
- 編集できる Git リポジトリに FoodSales.pbix ファイルをダウンロードします。 このチュートリアルではこのサンプル ファイルを使用します。 または、必要に応じて、自分で用意したセマンティック モデルとレポートを使用することもできます。
データを含むワークスペースに対する管理者権限が既にある場合は、 手順 3 に進むことができます。
手順 1: Premium ワークスペースを作成する
新しいワークスペースを作成し、ライセンスを割り当てるには:
Power BI エクスペリエンスの左側のナビゲーション バーから、ワークスペース > + 新しいワークスペースを選択します。
ワークスペースに FoodSalesWS という名前を付けます。
(省略可能) 説明を追加します。
[ 詳細 ] セクションを展開して、 ライセンス モードを表示します。
試用版または Premium 容量を選択します。
[ 適用] を選択します。
ワークスペースの作成の詳細については、「ワークスペースの 作成」を参照してください。
手順 2: ワークスペースにコンテンツを読み込む
OneDrive、SharePoint、ローカル ファイルからコンテンツをアップロードできます。 このチュートリアルでは、 .pbix ファイルを読み込みます。
上部のメニュー バーで、[ アップロード] > [参照] を選択します。
前にダウンロードした FoodSales.pbix ファイルの場所を参照するか、独自のサンプル セマンティック モデルとレポートを読み込みます。
これで、自分とチームが作業できるコンテンツを含むワークスペースが作成されました。
資格情報の編集 - 初回のみ
デプロイ パイプラインを作成する前に、資格情報を設定する必要があります。 このステップは、セマンティック モデルごとに 1 回だけ実行する必要があります。 このセマンティック モデルに資格情報を設定したら、再度設定する必要はありません。
Power BI の設定>設定に移動します。
[資格情報の編集] >[データ ソース資格情報] >セマンティック モデルを選択します。
[認証方法] を [匿名] に設定し、[プライバシー] レベルを [パブリック] に設定し、[テスト接続のスキップ] ボックスをオフにします。
[ サインイン] を選択します。 接続がテストされ、資格情報が設定されます。
これでデプロイ パイプラインを作成できるようになりました。
手順 3: チームの開発ワークスペースを Git に接続する
チーム全体でこのワークスペースを共有し、チームの各メンバーが編集できます。 このワークスペースを Git に接続することで、すべての変更を追跡し、必要に応じて以前のバージョンに戻すことができます。 すべての変更がこの共有ブランチにマージされたら、デプロイ パイプラインを使ってワークスペースを運用環境にデプロイします。
Git を使用したバージョン管理の詳細については、「 Git 統合の概要」を参照してください。
このワークスペースを Azure リポジトリの メイン ブランチに接続して、すべてのチーム メンバーが編集とプル リクエストの作成をできるようにします。 Azure DevOps リポジトリを使用している場合は、次の手順に従います。 GitHub リポジトリを使用している場合は、「 ワークスペースを GitHub リポジトリに接続する」の指示に従ってください。
右上隅の [ワークスペースの設定 ] に移動します。
[Git 統合] を選択します。
[Azure DevOps] を選択します。 ワークスペースにサインインした Microsoft Entra ユーザーに登録されている Azure Repos アカウントに自動的にサインインします。
ドロップダウン メニューから、接続するブランチに関する以下の詳細情報を指定します。
[ 接続と同期] を選択します。
接続後、ワークスペースにはソース管理に関する情報が表示されます。これにより、接続されたブランチ、ブランチ内の各項目の状態、最後の同期時刻を表示できます。ワークスペースの Git リポジトリ内の各項目とまったく同じであるため、[ソース管理] アイコンには 0 が表示されます。
これで、ワークスペースが Git リポジトリのメイン ブランチと同期され、変更を簡単に追跡できるようになりました。
git への接続の詳細については、「ワークスペースを Azure リポジトリに接続する」を参照してください。
手順 4: デプロイ パイプラインを作成する
このワークスペースを他のユーザーと共有し、テストと開発のさまざまな段階で使用するには、デプロイ パイプラインを作成する必要があります。 デプロイ パイプラインのしくみについては、「デプロイ パイプラインの 概要」を参照してください。 デプロイ パイプラインを作成し、ワークスペースを開発ステージに割り当てるには、次の手順を行います:
ワークスペースのホーム ページで、[ デプロイ パイプラインの作成] を選択します。
パイプライン に FoodSalesDP という名前を付け、説明 (省略可能) を指定し、[ 次へ] を選択します。
パイプラインには既定の 3 つのステージをそのまま使用し、[ 作成] を選択します。
FoodSalesWS ワークスペースを開発ステージに割り当てます。
デプロイ パイプラインの開発ステージには、1 つのセマンティック モデル、1 つのレポート、1 つのダッシュボードが表示されます。 他のステージは空です。
デプロイ パイプラインの作成の詳細については、「 デプロイ パイプラインの概要」を参照してください。
手順 5: 他のステージにコンテンツをデプロイする
次に、パイプラインの他のステージにコンテンツをデプロイします。
展開コンテンツ ビューの開発ステージで、[デプロイ] を選択 します。
コンテンツをテスト ステージにデプロイしてもよいか確認します。
緑色のチェック アイコンは、パイプラインのコンテンツ全体をデプロイしたため、2 つのステージの内容が同一であることを示します。
テスト ステージから運用ステージにコンテンツをデプロイします。
任意のステージでセマンティック モデルを更新するには、各ステージの概要カードにあるセマンティック モデル アイコンの横にある [更新] ボタンを選択します。
チーム全体でこのデプロイメント パイプラインを共有します。 各チーム メンバーは、開発ステージのセマンティック モデルとレポートを編集できます。 チームが変更をテストする準備ができたら、コンテンツをテスト ステージにデプロイします。 チームは、変更を運用環境にリリースする準備ができたら、コンテンツを運用ステージにデプロイします。
コンテンツの展開の詳細については、「コンテンツの 展開」を参照してください。
手順 6: 隔離されたワークスペースを作成する
共有ワークスペースを編集したり、他のチーム メンバーの変更を妨げたりしないように、各チーム メンバーは、変更をチームと共有する準備ができるまで、自分だけの隔離されたワークスペースを作成して作業する必要があります。
[ソース管理] メニューの [ブランチ] タブで、現在のブランチ名の横にある下矢印を選択し、[新しいワークスペースに分岐] を選択します。
ブランチとワークスペースに関する次の詳細を指定します。 新しいブランチは、現在のワークスペースに接続されているブランチに基づいて自動的に作成されます。
- ブランチ名 (このチュートリアルでは MyFoodEdits という名前を付けます)
- ワークスペース名 (このチュートリアルでは、 My_FoodSalesという名前を付けます)
[ ブランチアウト] を選択します。
[ 接続と同期] を選択します。
Fabric によって新しいワークスペースが作成され、新しいブランチに同期されます。 新しいワークスペースに自動的にアクセスされますが、同期には数分かかる場合があります。
新しいワークスペースに Git リポジトリ フォルダーの内容が入ります。
.pbix ファイルが含まれていないことに注意してください。
.pbix ファイルはサポートされていないため、同期時にこのファイルは Git リポジトリにコピーされませんでした。
チームと共有する準備ができるまで、このワークスペースを使用してセマンティック モデルとレポートに変更を加えます。
手順 7: ワークスペースを編集する
分岐したワークスペースが同期されたら、アイテムを作成、削除、または編集することで、ワークスペースに変更を加えることができます。 このチュートリアルでは、セマンティック モデル列の書式を変更します。 Power BI Desktop またはデータ モデルでワークスペースを編集できます。 このチュートリアルでは、データ モデルでワークスペースを編集します。
セマンティック モデル ワークスペースから、セマンティック モデルの省略記号 (3 つのドット) >Open データ モデルを選択します。
注記
[データ モデルを開く] が無効になっている場合は、Power BI > General >ワークスペース設定に移動し、データ モデルの設定を有効にします。
Order_detailsテーブルで、[割引] を選択します。
[プロパティ] ウィンドウで、[書式] を [全般] から [パーセンテージ] に変更します。
手順 8: 変更をコミットする
この変更をワークスペースから Git ブランチにコミットするには、ワークスペースのホーム ページに戻ります。
ワークスペース内で 1 つの項目が変更されたが、Git リポジトリにコミットされていないため、[ソース管理] アイコンに 1 が表示されるようになりました。
FoodSales セマンティック モデルは、コミットされていない状態を示します。
[ソース管理] アイコンを選択して、Git リポジトリ内で変更された項目を表示します。 セマンティック モデルには、[変更済み] のステータスが表示されます。
コミットする項目を選択し、任意のメッセージを追加します。
「コミット」を選択します。
セマンティック モデルの Git ステータスが [同期済み] に変わり、ワークスペースと Git リポジトリが同期されていることがわかります。
手順 9: PR を作成してマージする
Git リポジトリで、MyFoodEdits ブランチをメイン ブランチとマージするプル要求を作成します。
この手順は、手動でも自動でも実行できます。
プルリクエストを作成を選択します。
pull request に必要なタイトル、説明、その他の情報を入力します。 次に、[ 作成] を選択します。
-
変更がメイン ブランチに統合されたら、必要に応じてワークスペースを安全に削除できます。 それは自動的には削除されません。
手順 10: 共有ワークスペースを更新する
デプロイ パイプラインの開発ステージ ( 手順 1 で作成したワークスペース) に接続されている共有ワークスペースに戻り、ページを更新します。
Git リポジトリ内の 1 つの項目が変更され、FoodSales ワークスペース内の項目とは異なるようになったため、ソース管理アイコンに 1 が表示されるようになりました。 FoodSales セマンティック モデルには、[更新が必要] のステータスが表示されます。
ワークスペースの更新は、手動でも自動でも行うことができます。
[ソース管理] アイコンを選択して、Git リポジトリ内で変更された項目を表示します。 セマンティック モデルには、[変更済み] のステータスが表示されます。
[ すべて更新] を選択します。
セマンティック モデルの Git ステータスが [同期済み] に変わり、ワークスペースは "メイン" の Git ブランチと同期されます。
手順 11: デプロイ パイプラインのステージを比較する
[ デプロイ パイプラインの表示 ] を選択して、開発ステージのコンテンツとテスト ステージのコンテンツを比較します。
両ステージの間にあるオレンジ色の
Xアイコンは、前回のデプロイ以降にいずれかのステージでコンテンツに変更が加えられたことを示しています。
[>の確認] 下矢印を選択して、変更を表示します。 [変更レビュー] 画面には、2 つの段階のセマンティック モデルの違いが表示されます。
変更を確認し、ウィンドウを閉じます。
デプロイ パイプラインのステージの比較の詳細については、「デプロイ パイプライン のステージを比較する」を参照してください。
手順 12: テスト ステージにデプロイする
変更に満足したら、 手順 5 で使用したのと同じプロセスを使用して、テスト ステージまたは運用ステージに変更をデプロイします。
まとめ
このチュートリアルでは、デプロイ パイプラインと Git 統合を利用して、ワークスペース内のアプリ、レポート、その他のコンテンツのライフサイクルを管理する方法について説明しました。
特に、次の方法を学習しました。
- ワークスペースをセットアップし、Fabric でライフサイクルを管理するコンテンツを追加します。
- Git のベスト プラクティスを適用して、変更に関する単独作業またはチームメイトとの共同作業を行う。
- Git とデプロイ パイプラインを組み合わせて、効率的なエンド ツー エンドのリリース プロセスを実現する。