Microsoft Fabric Git統合 × Azure DevOps -別テナント間でFabricアイテムをリリースする方法-

はじめに

Microsoft Fabric のデプロイ パイプラインは、基本的に同一テナント内のワークスペース間での利用が前提です。
そのため、開発環境と本番環境を別テナントで分離している構成では、どのようにリリースを行うかが悩みどころになります。

今回は、Azure DevOps の Repos と Fabric の Git 統合を使って、別テナント間でリリースできるかを検証しました。
具体的には、テナントB（開発）で作業した内容を、テナントA（本番）へ反映する構成です。

今回はできるだけシンプルに確認するため、1つのリポジトリの中でブランチを分ける構成としました。イメージとしては以下の通りです。

└─ main -----> テナントAのワークスペースA（本番）
　　　 └─ dev -----> テナントBのワークスペースB（開発）

つまり、開発ワークスペースを dev ブランチ、本番ワークスペースを main ブランチに接続し、dev から main へのプルリクエストとマージによってリリースする流れです。

公式ドキュメントにも、テナントをまたいだ Azure DevOps との連携が可能であることを読み取れる記載があります。
そこで今回は、実際に試してみたうえで、具体的な手順と躓きやすいポイントをまとめました。

手順

ゲストユーザー招待

テナントBのEntraポータルの[ユーザー]>[新しいユーザー]>[外部ユーザーの招待]
からユーザーAのメールアドレスを入力し、テナントBのゲストユーザーとして招待します。

招待後、ユーザーAに招待メールが届くので承認をします。

テナントBワークスペースのDevOpsの設定

DevOpsライセンスの開始

今回私はテナントBのユーザーBを用いてのDevOpsの開始から始めました。
１テナント5ユーザーまではBasicライセンスを無料で使えます。

DevOpsのリージョンについて
現在DevOpsのリージョンに[Japan]はサポートされていません。
今回は[Southeast Asia]を選択しています。

レポジトリ作成

ユーザーBを用いて
DevOpsに組織>プロジェクト>レポジトリの順で新規作成していきます。
その後、mainブランチに加えてdevブランチも作成します。

ゲストユーザーをテナントBのDevOpsユーザーにする

Devopsのホームに戻り、[Organization settings]に進みます

[Security]>[Policies]から
[External guest access]を有効化します。

次に同じく[Organization settings]の
[Users]から[Add Users]をクリックし、
対象のプロジェクトと権限を設定します。
今回は[Project Contributors]を選択しています。

FabricのGit統合を行う

ワークスペース権限「管理者」が必要になります。

FabricとDevOpsのリージョンついて
両者のリージョンが一致していない場合エラーとなります。
詳細と解決方法については以下をご参照ください

https://qiita.com/manabian/items/362a65b0956b3c9c1c92

https://learn.microsoft.com/ja-jp/fabric/admin/git-integration-admin-settings

テナントB FabricとテナントB DevOpsを統合する

ユーザーBを用いてテナントBのFabricのワークスペースBにアクセスします。

[ワークスペース設定]>[git 統合]>[Azure DevOps]と進みます。

[Entraアカウント]>[接続]をクリックします。

対象の組織・プロジェクト・リポジトリを選択し、
ブランチは[dev]を選びます。（開発ワークスペースなので）

[接続と同期]をクリックします。

ワークスペース右上に[ソース管理]という項目が出てきたら接続完了です。

テナントA FabricとテナントB DevOpsを統合する

こちらが躓きポイントになりやすいです。

今回は、ユーザーAを用いてテナントAのFabricのワークスペースAにアクセスします。

[ワークスペース設定]>中略>[Entraアカウント]までは同じ手順ですが、

[アカウント]から [アカウントの追加] をクリックします。

任意の接続名で問題ありませんが、
テナントBのAzure DevOpsのリポジトリまでのURL が必要になります。
認証は今回、OAuthを選択しました。

すると[アカウント欄]に今追加したアカウントが表示されるので
そちらを選択し、[接続]をクリックします。

対象の組織・プロジェクト・リポジトリを選択し、
今回、ブランチは　[main]　を選びます。（本番ワークスペースなので）

同様に
ワークスペース右上に[ソース管理]という項目が出てきたら接続完了です。

DevOpsを使ってリリースしてみる

リリースの流れを簡単に紹介します。

ワークスペースBで変更・コミット

ワークスペースBで新しくノートブックを作成します。

作成後、ワークスペース画面に戻り[ソース管理]を開きます。
変更されたものが認識されるので、[コミット]をクリックします。

DevOpsでプルリクエスト

DevOpsの[dev]ブランチを開き、
先ほど作成したノートブックがフォルダとして追加されたことを確認します。

[Repos]の[Pull requests]に進み、
[New Pull requests]をクリックします。

プルリクエストの方向が
[dev]→[main]であることを確認し、
[Create]をクリックします。

続いて次の画面に遷移したら、今回はそのまま[Complete]もクリックし、マージを完了させます。

[main]ブランチに移動し、プルリクエストによってノートブックがファイルとして追加されたことを確認します。

mainブランチとワークスペースAを同期

ユーザーAを用いてワークスペースAにアクセスします。
すると、[ソース管理]の項目に更新情報が届いているので[すべて更新]をクリックします。

ノートブックが追加され、リリースが完了しました！

今後の検討事項

今回の検証では、1つのリポジトリ内で dev / main ブランチを分ける構成で、別テナント間でもリリースできることを確認できました。
一方で、実運用を考えると、まだ整理しておきたい論点があるのでまとめておきます。

• 開発用と本番用でリポジトリ自体を分ける場合のリリース方法

  • 今回は1つのリポジトリ内でブランチを分けましたが、運用ルールや権限分離の観点から、リポジトリ自体を分けたいケースもあります。その場合にどのようなリリースフローが現実的かは、別途検討が必要そうです。

• 条件付きアクセスポリシーとの兼ね合い

  • 別テナント接続では、Entra ID 側の条件付きアクセスやゲストユーザー制御の影響を受けやすいです。環境によっては今回の手順通りに進まない可能性もあるため、確認は重要だと感じました。

• Fabric アイテムごとの制限事項

  • 今回はノートブックで動作確認しましたが、Fabric ではアイテムごとに Git 統合やデプロイ時の挙動が異なる場合があります。実際に運用へ乗せる場合は、対象となるアイテムごとの制約も確認しておきたいところです。

Youtubeもやってます！

FabricやDatabricksについて学べる勉強会を毎月開催！

次回イベント欄から直近のMicrosoft Data Analytics Day(Online) 勉強会ページへ移動後、申し込み可能です！

関連記事