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 ワークスペースを使用している同じユーザーに登録されているアクティブな Azure アカウント。 無料アカウントを作成します。
- 既存のリポジトリにアクセスします。
開発プロセス
Fabric ワークスペースは、ライブ項目にアクセスする共有環境です。 ワークスペースで直接行われた変更は、他のすべてのワークスペース ユーザーに対してオーバーライドされ、影響します。 そのため、Git のベスト プラクティスは、開発者が共有ワークスペースの外部に分離された状態で作業することです。 開発者が独自の保護されたワークスペースで作業するには、2 つの方法があります。
- レポートやセマンティック モデル用の Power BI Desktop、Notebook用の VS Code などのクライアント ツールを使用して開発します。
- 別個のFabric ワークスペースで開発します。 各開発者が独自のワークスペースを持ち、そこに別個の独自ブランチを接続し、そのワークスペースにコンテンツを同期してから、ブランチにコミットして戻します。
Git 統合を使用してブランチを操作するには、まず共有開発チームのワークスペースを 1 つの共有ブランチに接続します。 たとえば、チームが 1 つの共有ワークスペースを使用している場合は、それをチームのリポジトリの "メイン" ブランチに接続し、ワークスペースとリポジトリの間で同期します。 チームのワークフローに "開発/テスト/実働" ブランチなどの複数の共有ブランチがある場合は、各ブランチを異なるワークスペースに接続できます。
これで、各開発者が、作業する分離環境を選択できます。
シナリオ 1 - クライアント ツールを使用して開発する
開発中のアイテムが他のツールで使用できる場合は、クライアント ツールでこれらのアイテムを直接操作できます。 すべての項目がすべてのツールで使用できるわけではありません。 Fabric でのみ使用できる項目は、Fabric で開発する必要があります。
Power BI Desktop などのクライアント ツールを使用する開発者向けのワークフローは、次のようになります。
リポジトリをローカル コンピューターに複製します。 (この操作を行う必要があるのは 1 回のみです)
"PBIProj" のローカル コピーを使用して、Power BI Desktop でプロジェクトを開きます。
変更を加え、更新されたファイルをローカルに保存します。 ローカル リポジトリにコミットします。
準備ができたら、ブランチをプッシュし、リモート リポジトリにコミットします。
他の項目や複数のデータに対して変更内容をテストします。それには、新しいブランチを別個のワークスペースに接続し、ソース管理パネルの [すべて更新] ボタンを使用してセマンティック モデルとレポートをアップロードします。 "メイン" ブランチにマージする前に、そこでテストや構成の変更をすべて行ってください。
ワークスペースでテストする必要がない場合、開発者は、別のワークスペースを必要とせずに、"メイン" ブランチに変更内容を直接マージできます。
変更がマージされると、新しいコミットを受け入れるように求めるダイアログが共有チームのワークスペースに表示されます。 変更内容が共有ワークスペースに対して更新され、すべてのユーザーがそれらのセマンティック モデルとレポートに対する変更を確認できます。
Git で新しい Power BI Desktop ファイル形式を使用する方法に関する特定のガイダンスについては、ソース コード形式に関するページを参照してください。
シナリオ 2 - 別のワークスペースを使用して開発する
Web で作業する開発者の場合、フローは次のようになります。
[ソース管理] メニューの [ブランチ] タブで、[新しいワークスペースへの分岐] を選択します。
ブランチとワークスペースの名前を指定しています。 現在のワークスペースに接続されているブランチに基づいて作成された新しいブランチ。
[ブランチ アウト] を選択します。
Fabric は、新しいワークスペースとブランチを作成します。 新しいワークスペースに自動的にアクセスされます。
ワークスペースは機能ブランチと同期され、図に示すように、作業する分離された環境になります。 これで、この新しい分離環境で作業できるようになりました。 同期には数分かかることがあります。 ブランチ アウト に関する詳細については、「トラブルシューティングのヒント」を参照してください。
変更内容を保存し、機能ブランチにコミットします。
準備ができたら、"メイン" ブランチに対する PR を作成します。 そのリポジトリに対してチームが定義した構成に基づいて、Azure Repos 経由でレビューとマージのプロセスが実行されます。
レビューとマージが完了すると、"メイン" ブランチに対して新しいコミットが作成されます。 このコミットは、開発チームのワークスペース内のコンテンツをマージされた変更内容で更新するように求めるダイアログをユーザーに表示します。
詳細については、「ブランチ アウトの制限事項」を参照してください。
リリース プロセス
リリース プロセスは、新しい更新が pull request プロセスを完了し、チームの共有ブランチ (Main、Dev など) にマージすると始まります。 ここからは、Fabric でリリース プロセスを構築するためのさまざまなオプションの概要を説明します。 リリース プロセスのさまざまな考慮事項については、デプロイ パイプラインの管理に関する記事をご覧ください。
ブランチを切り替える
ワークスペースが Git ブランチに接続されていて、別のブランチに切り替えたい場合は、切断と再接続を行わずに [ソース管理] パネルから直ちに実行できます。
ブランチを切り替えると、ワークスペースは新しいブランチと同期され、ワークスペース内のすべての項目がオーバーライドされます。 各ブランチに同じ項目の異なるバージョンがある場合は、項目が置き換えられます。 項目が古いブランチにあり、新しいブランチにはない場合は、削除されます。
ブランチを切り替えるには、次の手順に従います。
[ソース管理] メニューの [ブランチ] タブで、[ブランチの切り替え] を選びます。
接続するブランチを指定するか、新しいブランチを作成します。 このブランチには、現在のブランチと同じディレクトリが含まれている必要があります。
[ブランチの切り替え] を選びます。
ワークスペースにコミットされていない変更がある場合、ブランチを切り替えることはできません。 [キャンセル] を選んで戻り、変更をコミットしてからブランチを切り替えてください。
既存のワークスペースの状態を維持したまま、現在のワークスペースを新しいブランチに接続するには、[新しいブランチのチェックアウト] を選びます。 新しいブランチのチェックアウトについて詳しくは、「Git で競合を解決する」をご覧ください。