Microsoft Fabric ワークスペースでブランチを管理する
この記事の目的は、一般的な顧客シナリオに基づき、Fabric で CI/CD プロセスを構築するためのさまざまなオプションを、Fabric 開発者に示すことです。 この記事では、CI/CD プロセスの "継続的インテグレーション (CI)" の部分に特に注目します。 継続的デリバリー (CD) の部分については、デプロイ パイプラインの管理に関する記事をご覧ください。
この記事では、いくつかの統合オプションの概要を個別に説明しますが、多くの組織はそれらを組み合わせて使っています。
前提条件
Git を Microsoft Fabric ワークスペースに統合するには、Fabric と Git の両方に対して次の前提条件を設定する必要があります。
Fabric の前提条件
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 アカウント。 無料アカウントを作成します。
- 既存のリポジトリにアクセスします。
開発プロセス
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 で作業する開発者の場合、フローは次のようになります。
ソース管理の メニューの [ブランチ] タブで、[ブランチを別のワークスペースに出力する] を選択します。
新しいワークスペースを作成するか、既存のワークスペースに切り替えるかを指定します。 新しいブランチとワークスペースの名前を指定するか、ドロップダウン リストから既存のワークスペースを選択します。 ワークスペースに分岐すると、Git に保存されていない項目が失われる可能性があります。 分岐する前に、保持する項目をコミットすることをお勧めします。
[ブランチ アウト] を選択します。
Fabric は、新しいワークスペースとブランチを作成します。 新しいワークスペースに自動的にアクセスされます。
ワークスペースは機能ブランチと同期され、図に示すように、作業する分離された環境になります。 これで、この新しい分離環境で作業できるようになりました。 同期には数分かかることがあります。 分岐の詳細については、トラブルシューティングのヒントを参照してください。
変更内容を保存し、機能ブランチにコミットします。
準備ができたら、"メイン" ブランチに対する PR を作成します。 そのリポジトリに対してチームが定義した構成に基づいて、Azure Repos 経由でレビューとマージのプロセスが実行されます。
レビューとマージが完了すると、"メイン" ブランチに対して新しいコミットが作成されます。 このコミットは、開発チームのワークスペース内のコンテンツをマージされた変更内容で更新するように求めるダイアログをユーザーに表示します。
詳細については、分岐制限事項を参照してください。
リリース プロセス
リリース プロセスは、新しい更新プログラムが Pull Request プロセスを完了し、チームの共有ブランチ (Main、Devなど) にマージすると開始されます。 この時点から、Fabric でリリース プロセスを構築するためのさまざまなオプションがあります。 ワークフローの設計時に考慮すべきさまざまなオプションについては、リリース プロセス 参照してください。
ブランチを切り替える
ワークスペースが Git ブランチに接続されていて、別のブランチに切り替えたい場合は、切断と再接続を行わずに [ソース管理] パネルから直ちに実行できます。
ブランチを切り替えると、ワークスペースは新しいブランチと同期され、ワークスペース内のすべての項目がオーバーライドされます。 各ブランチに同じ項目の異なるバージョンがある場合は、項目が置き換えられます。 項目が古いブランチにあり、新しいブランチにはない場合は、削除されます。
ブランチを切り替えるには、次の手順に従います。
[ソース管理] メニューの [ブランチ] タブで、[ブランチの切り替え] を選びます。
接続するブランチを指定するか、新しいブランチを作成します。 このブランチには、現在のブランチと同じディレクトリが含まれている必要があります。
[ブランチの切り替え] を選びます。
ワークスペースにコミットされていない変更がある場合、ブランチを切り替えることはできません。 [キャンセル] を選んで戻り、変更をコミットしてからブランチを切り替えてください。
既存のワークスペースの状態を維持したまま、現在のワークスペースを新しいブランチに接続するには、[新しいブランチのチェックアウト] を選びます。 新しいブランチのチェックアウトの詳細については、「Git で競合を解決する」を参照してください。