Microsoft Fabric ワークスペースでブランチを管理する

この記事の目的は、一般的な顧客シナリオに基づいて、Fabric で CI/CD プロセスを構築するためのさまざまなオプションを Fabric 開発者に提示することです。 この記事では、CI/CD プロセスの 継続的インテグレーション (CI) の部分について詳しく説明します。 継続的デリバリー (CD) パートの詳細については、デプロイ パイプラインの管理に関するページを参照してください。

この記事では、いくつかの異なる統合オプションの概要を説明しますが、多くの組織ではそれらの組み合わせを使用しています。

前提条件

Git を Microsoft Fabric ワークスペースに統合するには、Fabric と Git の両方に対して次の前提条件を設定する必要があります。

Fabric の前提条件

Git 統合機能にアクセスするには、次のいずれかが必要です。

• Power BI Premium ライセンス。 Power BI Premium ライセンスでは、すべての Power BI アイテムのみがサポートされます。
• Fabric の容量。 サポートされているすべての Fabric 項目を使用するには、Fabric 容量が必要です。 お持ちでない場合は、無料試用版にサインアップしてください。

さらに、管理ポータルから次の テナント スイッチ を有効にする必要があります。

• ユーザーは Fabric 項目を作成できる
• ユーザーはワークスペースのアイテムをGitリポジトリと同期できる
• GitHub ユーザーのみ: ユーザーは、ワークスペース項目を GitHub リポジトリと同期できる

これらのスイッチは、 組織の設定に応じて、テナント管理者、容量管理者、またはワークスペース管理者が有効にすることができます。

Git の前提条件

現在、Git 統合は Azure DevOps と GitHub でサポートされています。 Fabric ワークスペースと Git 統合を使用するには、Azure DevOps または GitHub で次のものが必要です。

開発プロセス

Fabric ワークスペースは、ライブ項目にアクセスする共有環境です。 ワークスペースで直接行われた変更は、他のすべてのワークスペース ユーザーに対してオーバーライドされ、影響します。 そのため、Git のベスト プラクティスは、開発者が共有ワークスペースの外部に分離された状態で作業することです。 開発者が独自の保護されたワークスペースで作業するには、2 つの方法があります。

• レポートやセマンティック モデル用の Power BI Desktop、Notebook用の VS Code などのクライアント ツールを使用して開発します。
• 別個のFabric ワークスペースで開発します。 各開発者が独自のワークスペースを持ち、そこに別個の独自ブランチを接続し、そのワークスペースにコンテンツを同期してから、ブランチにコミットして戻します。

Git 統合を使用してブランチを操作するには、まず共有開発チームのワークスペースを 1 つの共有ブランチに接続します。 たとえば、チームが 1 つの共有ワークスペースを使用している場合は、それをチームのリポジトリの "メイン" ブランチに接続し、ワークスペースとリポジトリの間で同期します。 チームのワークフローに "開発/テスト/実働" ブランチなどの複数の共有ブランチがある場合は、各ブランチを異なるワークスペースに接続できます。

これで、各開発者が、作業する分離環境を選択できます。

シナリオ 1 - クライアント ツールを使用した開発

開発中のアイテムが他のツールで使用できる場合は、クライアント ツールでこれらのアイテムを直接操作できます。 すべての項目がすべてのツールで使用できるわけではありません。 Fabric でのみ使用できる項目は、Fabric で開発する必要があります。

Power BI Desktop などのクライアント ツールを使用する開発者向けのワークフローは、次のようになります。

1. リポジトリをローカル コンピューターに複製します。 (この操作を行う必要があるのは 1 回のみです)

2. "PBIProj" のローカル コピーを使用して、Power BI Desktop でプロジェクトを開きます。

3. 変更を加え、更新されたファイルをローカルに保存します。 ローカル リポジトリにコミットします。

4. 準備ができたら、ブランチをプッシュし、リモート リポジトリにコミットします。

5. 他の項目や複数のデータに対して変更内容をテストします。それには、新しいブランチを別個のワークスペースに接続し、ソース管理パネルの [すべて更新] ボタンを使用してセマンティック モデルとレポートをアップロードします。 "メイン" ブランチにマージする前に、そこでテストや構成の変更をすべて行ってください。

   ワークスペースでテストする必要がない場合、開発者は、別のワークスペースを必要とせずに、"メイン" ブランチに変更内容を直接マージできます。

6. 変更がマージされると、新しいコミットを受け入れるように求めるダイアログが共有チームのワークスペースに表示されます。 変更内容が共有ワークスペースに対して更新され、すべてのユーザーがそれらのセマンティック モデルとレポートに対する変更を確認できます。

Git で新しい Power BI Desktop ファイル形式を使用する方法に関する特定のガイダンスについては、ソース コード形式に関するページを参照してください。

シナリオ 2 - 別のワークスペースを使用して開発する

Web で作業する開発者の場合、フローは次のようになります。

1. [ソース管理] メニューの [ブランチ] タブで、[新しいワークスペースへの分岐] を選択します。

   

2. ブランチとワークスペースの名前を指定しています。 現在のワークスペースに接続されているブランチに基づいて作成された新しいブランチ。

   

3. [ブランチ アウト] を選択します。

   Fabric は、新しいワークスペースとブランチを作成します。 新しいワークスペースに自動的にアクセスされます。

   ワークスペースは機能ブランチと同期され、図に示すように、作業する分離された環境になります。 これで、この新しい分離環境で作業できるようになりました。 この処理には数分かかる場合があります。 ブランチ アウト に関する詳細については、「トラブルシューティングのヒント」を参照してください。

   

4. 変更内容を保存し、機能ブランチにコミットします。

5. 準備ができたら、"メイン" ブランチに対する PR を作成します。 そのリポジトリに対してチームが定義した構成に基づいて、Azure Repos 経由でレビューとマージのプロセスが実行されます。

レビューとマージが完了すると、"メイン" ブランチに対して新しいコミットが作成されます。 このコミットは、開発チームのワークスペース内のコンテンツをマージされた変更内容で更新するように求めるダイアログをユーザーに表示します。

詳細については、「ブランチ アウトの制限事項」を参照してください。

リリース プロセス

リリース プロセスは、新しい更新プログラムが Pull Request プロセスを完了し、チームの共有ブランチ ("Main"、"Dev" など) にマージされると開始されます。 この時点から、Fabric でリリース プロセスを構築するためのさまざまなオプションの概要を説明します。 リリース プロセスに関するさまざまな考慮事項については、デプロイ パイプラインの管理に 関するページを参照してください。

ブランチを切り替える

ワークスペースが Git ブランチに接続されていて、別のブランチに切り替えたい場合は、切断と再接続を行わずに [ソース管理] パネルから直ちに実行できます。
ブランチを切り替えると、ワークスペースは新しいブランチと同期され、ワークスペース内のすべての項目がオーバーライドされます。 各ブランチに同じ項目の異なるバージョンがある場合は、項目が置き換えられます。 項目が古いブランチにあり、新しいブランチにはない場合は、削除されます。 ブランチを切り替えるには、次の手順に従います。

1. [ソース管理] メニューの [ブランチ] タブで、[新しいブランチのチェックアウト] を選択します。

   

2. 接続するブランチを指定します。 このブランチには、現在のブランチと同じディレクトリが含まれている必要があります。

3. [チェックアウト ブランチ] を選択 します。

ワークスペースに未保存の変更内容がある場合、まずブランチを保存することなくブランチを切り替えると、それらは失われます。 [キャンセル] を選択して戻り、ブランチを切り替える前に変更内容を保存してください。

関連するコンテンツ

• エラーと競合を解決する
• Git 統合のベスト プラクティス