ノートブックのソース管理とデプロイ

この記事では、Microsoft Fabric のノートブックで Git 統合パイプラインとデプロイ パイプラインを使用する方法について説明します。 リポジトリを接続し、ノートブックのソース コードを管理し、複数の環境にノートブックをデプロイする方法について説明します。

開始する前に

• ノートブックのソース管理手順を完了する前に、ワークスペースを Git に接続します。 セットアップ手順については、「 Git 統合の概要」を参照してください。
• 開発時ではなく、ターゲット ステージ (テストや運用など) にノートブック展開ルールを作成します。
• 展開ルールを作成するには、アイテムの所有者である必要があります。

ノートブック Git 統合

Fabric ノートブックでは、ソース管理のための Azure DevOps との Git 統合がサポートされています。 ノートブックの変更のバージョン管理、ブランチの使用による共同作業、および Fabric でのノートブックライフサイクルの更新の管理を直接行うことができます。

アタッチされた依存関係 (環境など) と共にノートブックをコミットすると、別のワークスペースに同期しても、これらのバインドは保持されます。 Fabric は、新しいワークスペース内の対応するリソースにノートブックを自動的にバインドします。

この動作をサポートするために、Fabric は接続されたリソースの論理識別子をノートブック メタデータに格納します。 その結果、Git の差分では、物理 ID から論理 ID へのメタデータの更新を表示できます。

接続を設定する

ワークスペース設定から、変更をコミットして同期するためのリポジトリへの接続を設定します。 セットアップ手順については、「 Git 統合の概要」を参照してください。 接続すると、ノートブックを含む項目が [ソース] コントロール パネルに表示されます。

ノートブック インスタンスを Git リポジトリにコミットすると、リポジトリ内のノートブック フォルダー構造を確認できます。

プル要求の作成などの Git 操作を実行できるようになりました。

Git でのノートブックの表現

次のテキストは、Git リポジトリ内のノートブック項目のファイル構造を示しています。

.
├── Notebook_1.Notebook/
│   ├── Resources/ (Optional)
│   │   └── builtin/
│   │       ├── large_dataset.parquet
│   │       └── model_output.parquet
│   ├── .platform
│   ├── fs-settings.json (Optional)
│   ├── notebook-content.py
│   └── notebook-settings.json (Optional)
└── Readme.md

.
├── Notebook_2.Notebook/
│   ├── Resources/ (Optional)
│   │   └── builtin/
│   │       ├── large_dataset.parquet
│   │       └── model_output.parquet
│   ├── .platform
│   ├── fs-settings.json (Optional)
│   ├── notebook-content.sql
│   └── notebook-settings.json (Optional)
└── Readme.md

ノートブック項目をコミットすると、Fabric は標準の .ipynb ファイルではなくソース ファイルとして保存します。 たとえば、PySpark ノートブックは notebook-content.pyとして格納されます。 この形式は、Git の差分で簡単に確認できます。

ソース ファイルは、ノートブックのメタデータ (既定の lakehouse とアタッチされた環境を含む)、マークダウン セル、コード セルを別々のセクションとして保持します。 ファブリックでは、ワークスペースに同期するときに、この構造を使用してノートブックを再構築します。

Git に同期する場合、ノートブックのセル出力は含まれません。

次のスクリーンショットは、Git リポジトリのソース形式を示しています。

Notebook Git の設定

[Git 設定] パネルでは、ノートブックとソース管理の対話方法を制御できます。これには、Git バインドのオプションや、コミットに含まれるリソース フォルダー ファイルの管理が含まれます。

Git におけるレイクハウスの自動バインド

Lakehouse Auto-Binding により、Fabric は Git に接続された各ワークスペースに対して正しい既定のレイクハウスを解決できます。 これにより、開発、テスト、運用の各ワークスペース間でノートブックを移動するときの手動再バインドが減ります。

ノートブックの設定からこの機能を有効にします。 有効にすると、Fabric によってリポジトリに notebook-settings.json が作成され、このファイルが自動的に管理されます。 このファイルは手動で編集しないでください。

Git での Notebooks リソース フォルダーのサポート

組み込みの Resources フォルダーは Git にコミットできるため、スクリプトと構成ファイルはノートブックでバージョン管理されます。

この機能は省略可能であり、既定ではオフになっています。 [Git 設定] セクションのノートブック設定から有効にします。 有効にすると、Resources フォルダー内のファイルがコミットに含まれます。 コミットには 50 MB の 制限があるため、 .gitignore ファイルまたは Git ルールを使用して、大きなファイルまたは一時ファイルまたはフォルダーを除外します。

Git ルールを構成して変更をコミットすると、Fabric はリポジトリの fs-settings.json にルールを保存します。 このファイルは、リポジトリの構成の一貫性を維持するために、Fabric によって生成および管理されます。 また、Git リポジトリでこのファイルを直接編集することはお勧めしません。

デプロイメントパイプラインにおけるノートブック

デプロイ パイプラインを使用して、 開発、 テスト、運用などのステージ間でノートブックの変更を昇格 します。 運用環境に昇格する前に、前のステージで更新プログラムを検証します。

ノートブックの展開では、依存する項目が同じワークスペースにある場合に、既定の lakehouse 環境とアタッチされた環境の自動バインドがサポートされます。 デプロイ時に、Fabric は、ターゲット ワークスペース内の対応する項目にこれらの依存関係を再バインドできます。 メタデータの変更は、差分ビューに表示されます。

特定のターゲット ステージの既定の lakehouse が必要な場合は、自動バインドをオーバーライドするようにデプロイ規則を構成します。

この記事では、現在、新しいデプロイ パイプライン UI を使用しています。 新しいデプロイ パイプラインをオフにすることで、古い UI に切り替えることができます。

デプロイ パイプラインを使用してノートブックをデプロイするには、次の手順に従います。

1. デプロイ パイプラインを作成するか、既存のものを開きます。 詳しくは、「展開パイプラインの使用を開始する」をご覧ください。

2. デプロイの目標に応じて、ワークスペースをさまざまなステージに割り当てます。

3. ノートブックを含む項目をステージ間で選択、表示、比較します。 強調表示されたバッジには、前のステージと現在のステージの間で変更された項目の数が表示されます。

   

4. [ デプロイ] を選択して、 開発、 テスト、 運用 の各段階でノートブックを昇格させます。

   

5. [ このステージへのデプロイ ] ウィンドウで、新しい項目と変更された項目を確認します。 1 つ以上の項目が失敗した場合でもデプロイを続行するには、 1 つ以上の項目が失敗した場合は [デプロイの続行] を選択します。

   選択内容を確認して確認したら、[デプロイ] を選択 します。

   

6. (省略可能)。)デプロイ ルールを作成するには、パイプライン内のターゲット ステージ項目 (テストや運用など) でデプロイ ルールを選択します。

   一般的なルールの動作と制限事項については、「 デプロイ ルールの作成」を参照してください。

   

7. ノートブックのデプロイごとに既定の lakehouse ルールを構成します。

   この規則では、デプロイ後のターゲット ステージでノートブックがどの lakehouse に接続するかを制御します。

   [ 配置ルールの設定 ] ウィンドウで、[ 既定の lakehouse ] タイルを選択します。

   ソース ステージの既定の lakehouse をターゲット ステージの既定の lakehouse にマップするには、[ From ] ドロップダウンと [ To ] ドロップダウンを使用します。

   • ソース レイクハウスと同じ: ソース ステージと同じ既定の lakehouse 設定を保持します。
   • N/A (既定のレイクハウスなし):ターゲット ステージの既定の lakehouse 設定を削除します。
   • その他: ソース ステージの既定の lakehouse を、ターゲット ステージの別のレイクハウスに置き換えます。

   [送信先] ドロップダウンで [その他] を選択した場合は、ターゲットのレイクハウスの詳細を指定します。

   • Lakehouse ID
   • レイクハウス名
   • Lakehouse ワークスペース ID

   

   注意

   この規則を構成するときは、Lakehouse ID が必要です。 アイテムの URL から lakehouse ID を取得できます。 デプロイ 規則は、自動バインドよりも優先されます。 展開規則が構成されている場合は、自動バインドされた lakehouse がオーバーライドされます。

8. デプロイ履歴からデプロイの状態をモニターします。

関連するコンテンツ

• パブリック API を使用した Fabric ノートブックの管理と実行
• Git 統合の概要
• デプロイ パイプラインの概要