最適な Fabric CI/CD ワークフローオプションを選択する

本記事では、Fabric開発者に対し、一般的な顧客シナリオに基づいてCI/CDプロセスをFabricで構築するためのさまざまな選択肢を提示します。この記事では、CI/CD プロセスの "継続的デプロイ" (CD) に特に注目します。 継続的統合(CI)部分については、Microsoft Fabricの開発プロセスを参照してください。

この記事では、さまざまな独立したオプションの概要を説明していますが、多くの組織ではハイブリッドアプローチが採用されています。

前提条件

この記事のオプションを使用して CI/CD プロセスを構築するには、次のものが必要です。

Microsoft Fabric サブスクリプション
Fabric ワークスペース (展開を構成するにはワークスペース管理者である必要があります)
Git ベースのオプション (1、2、4) の場合、サポートされている Git プロバイダー (Azure DevOpsまたはGitHub) が Git 統合によって接続されています

Note

オプション 3 では、Fabric のデプロイパイプラインを使用します。このオプションを使用するには、デプロイパイプライン機能へのアクセスと、パイプラインを作成および管理するためのアクセス許可も必要です。

開発プロセス

開発プロセスはどのデプロイシナリオでも同じであり、新しい更新プログラムを運用環境にリリースする方法とは無関係です。開発者がソース管理を使用するときは、分離された環境で作業する必要があります。 Fabric では、その環境はローカルコンピューター上の IDE (Power BI Desktop、VS Code など) でも、Fabric 内の別のワークスペースでもかまいません。開発プロセスに関するさまざまな考慮事項については、Microsoft Fabric の開発プロセスを参照してください。

Git Syncは、ワークスペースの変更をGitにコミットすることと、Gitからワークスペースを更新することの両方をサポートしています。 PR矢印は、機能変更を共有開発ブランチにマージする方向を示しており、双方向同期操作ではありません。

リリースプロセス

リリースプロセスが始まるのは、新しい更新プログラムが完成して pull request (PR) がチームの共有ブランチ (Main、Dev など) にマージされたときです。この時点以降、Fabric でリリースプロセスを構築するには、さまざまなオプションがあります。

次の表は、選択に役立つオプションをまとめたものです。多くのチームが複数のチームを組み合わせています。

オプション	真実の源	各段階でデプロイされる内容	展開のメカニズム	ステージごとの構成	最適な用途
1 - ステージごとのGit分岐	Git	ステージ独自の主要ブランチ	Git統合、fabric-cicd、またはFabric Items API	段階ごとの定義、fabric-cicd パラメーター化、または変数ライブラリの値セット	各ステージごとに別々のブランチを使用して変更を昇格させるチーム
2 - 共有リリースコミット	Git（進行中の作業はDev、リリースはMain）¹	メイン上の同じリリースタグ。まずテスト、次に検証と承認を経て本番。	fabric-cicd または Bulk Import Item Definitions API	fabric-cicdパラメータ化、カスタムスクリプト、変数ライブラリの値セット	各ステージごとにブランチを管理せず、共有リリースバージョンをテストや本番にデプロイするチーム
3 - デプロイパイプライン	Fabric ワークスペース（dev 経由の Git のみ）	前の段階のワークスペースの内容	Fabric UIまたはデプロイメントパイプラインAPI	展開規則と自動バインド	ワークスペース間での Fabric ネイティブなローコード展開を好むチーム
4 - ISV 向け CI/CD	Git（継続作業はDev、リリースはMain）	同じリリースタグを Main で、まず共有 Test、その後、検証と承認を経て各顧客の Prod ワークスペースで使用します	fabric-cicd または Bulk Import Item Definitions API (顧客ワークスペースごと)	顧客ごとのリリースパラメーター	顧客ごとの多くのワークスペースを管理する ISV

¹ オプション2では、 Dev ワークスペースのみがGitに接続されています。 TestとProdのワークスペースはGitに接続されていません。 Mainでリリースタグをプッシュすると、そのバージョンをテストにデプロイするパイプラインがトリガーされます。検証と承認が成功した後、パイプラインは同じタグとコミットSHAを本番環境にデプロイします。

これらのオプションは、Gitflowやトランクベース開発のような特定の分岐戦略を必要としません。重要なのは、各ステージが特定されたバージョン付きコミットをデプロイし、本番環境がテストしたコンテンツと同じものを受け取ることです。

オプション1と2は、リリースの整理やプロモーション方法が異なるもので、ツールの排他的な選択ではありません。どちらの選択肢もfabric-cicdまたはFabric ItemsのAPIと環境固有のパラメータ化を使用できます。オプション1は、別個のステージブランチを通じて変更を促進します。オプション2は Main 上のリリースタグを使い、同じコミットを テスト に展開し、検証と承認を経て本番に展開します。

デプロイメントプランは別のワークフローオプションではありません。オプション 1 ではサポートされている Git 操作を含むプランを、オプション 3 ではデプロイメントパイプラインを使用するか、またはオプション 1、2、4 では Bulk Import Item Definitions API を直接呼び出すことができます。 fabric-cicdライブラリは展開計画をサポートしておらず、バルクインポートモードを使用する場合も同様です。プランはデプロイメントの順序、依存関係、アクションを制御し、選択したワークフローは信頼できる情報源、各ステージでデプロイされるもの、ステージ構成を定義し続けます。

オプション1 - 各ステージのGitブランチからの定義ベースのデプロイ

このオプションを使うと、すべてのデプロイメントは Git から開始されます。各ステージには専用のプライマリブランチがあります:この例では Dev、 Test、 Prod です。 PRはそれらのブランチ間で変更を反映し、各ワークスペースはステージのブランチから定義を受け取ります。 Git統合、fabric-cicd、またはFabric Items APIを使って展開できます。 fabric-cicdやItemsのAPIを使う場合、ターゲットワークスペースはGit接続を必要としません。特徴的なのは各段階ごとに別々のブランチがあり、デプロイツールではないことです。

Dev ブランチに対する PR が承認され、マージされると、次のことが行われます。

例えば、Git連携でDevワークスペースをDevブランチから更新します。ユニットテストや必要な展開後の作業を実施してください。
Promotionしたい変更を含めて Test ブランチのPRを作成してください。リリースブランチを使って、その変更をチェリーピックすることができます。チームのレビューと承認の手順に従ってください。
Git統合、fabric-cicd、またはFabric Items APIを用いてTestブランチからTestワークスペースに特定のコミットをデプロイします。段階ごとの構成を適用し、自動または手動のテストを実施してください。
検証済みの変更を反映する Prod ブランチへの PR を作成します。得られた定義を確認し、意図的なステージ固有の構成を除き、テストされたリリースに合致しているか確認してください。他の変更を追加する場合は、昇格前に Test で検証してください。
承認後、選択したデプロイメントツールを使ってProdブランチをProdワークスペースに展開します。必要な展開後のチェックとデータ取り込み操作を実行してください。

一部のアイテム依存関係は論理IDを介して自動的にバインドされます。他にはパラメーター化やデプロイ後の更新が必要です。詳細は「クロスワークスペース展開における依存関係バインディングの理解」を参照してください。

オプション#1の実装に使えるコンポーネントは何でしょうか?

Git統合:各ワークスペースをステージブランチに接続します。 Fabric UIを通じて更新するか、Fabric Git APIで自動更新してください。
fabric-cicd: ステージのブランチをチェックアウトし、環境固有のパラメーター付きアイテム定義を公開してください。ターゲットのワークスペースはGit接続を必要としません。
Fabric Items APIs: ステージのブランチから「アイテムを作成」および「アイテム定義の更新」、または Bulk Import Item Definitions API を呼び出して定義をデプロイできます。 APIを直接呼び出すと、自動化が定義や段階ごとの設定を準備します。

実装例については、fabric-cicdおよびAzure DevOpsのチュートリアル、またはFabric CI/CD with Bulk Import Item Definitions APIをご覧ください。

どのようなときにオプション 1 の使用を検討するか

信頼できる唯一の情報源として、またすべてのデプロイの origin として Git リポジトリを使用したいとき。
各段階ごとに別々のプライマリブランチを設け、段階間でPRベースの審査と昇格を設けたい場合。
Gitで段階ごとの定義を管理したい場合や、選択したデプロイメントツールで環境固有の設定を適用したい場合

オプション2 - 共有リリースコミットからの定義ベースのデプロイ

このオプションを使うと、開発者はDev Workspaceに接続されたDevブランチで作業します。 メインブランチはリリースブランチで、リリースする変更のみを含みます。 TestとProdのワークスペースはGitに接続されていません。 Mainでリリースタグをプッシュすると、GitHub ActionsのワークフローやAzure DevOpsのパイプラインが起動します。タグ付けされたバージョンを Test にデプロイし、検証を実行し、本番の承認を待ってから同じタグとコミット SHA を Prod にデプロイします。パイプラインはビルド環境を使ってユニットテストを実行し、アイテム定義を調整してからアップロードすることがあります。例えば、ターゲットステージのデータソース接続、他の項目への参照、またはパラメータ値を変更することができます。すべてのアイテム依存関係がこれらの変更を必要とするわけではありません。新しいワークスペースにデプロイした際に論理IDを介して自動的にバインドするものもあります。詳細は「クロスワークスペース展開における依存関係バインディングの理解」を参照してください。

リリースフローは以下の通りです:

開発者は承認済みのPRを Dev ブランチに統合し、 Dev ワークスペースはGitから更新されます。
リリースを準備するには、リリースしたい変更を Dev から Main に cherry-pick する PR を作成します。 PRには、あなたのチームや組織内の他のPRと同じ審査および承認プロセスを含めるべきです。
例えば、Main 上の選択したコミットにリリースタグを作成してください。v1.5.0 タグをプッシュすると、リリースタグ用に設定されたGitHub ActionsワークフローやAzure DevOpsパイプラインがトリガーされます。
パイプラインはタグをコミットSHAに解決し、両方を記録し、そのコミットをチェックアウトし、ユニットテストを実行し、Testの設定を調整します。 fabric-cicdまたはBulk Import Item Definitions APIを使って、それらのアイテム定義をTestワークスペースにアップロードします。詳細は「オプション#2を実装するために使えるコンポーネントは?」をご覧ください。デプロイ後は自動または手動によるテストを実施してください。検証が失敗した場合は、Prodへの昇格を停止してください。
検証が成功すると、パイプラインは設定された本番承認ゲートで待機します。 GitHub環境承認またはAzure DevOps環境承認チェックを使ってください。
承認後、同じリリースタグと記録されたコミットSHAを本番にデプロイします。Test と異なるのは、Variable Libraryの値セットやパラメータファイルなどのステージごとの構成のみです。本番環境特有のチェックを実行し、変更によって必要なデータ取り込みをトリガーして、消費者の利用不可を最小限に抑えます。

Important

本番環境に、テストでテストした正確なコミットをデプロイしてください。 メインが進んでも、記録されたコミットSHAを再利用してください。リリースタグを移動したり再利用したりして、別のコミットを指ささないようにしましょう。

検証が失敗した場合は、まず Dev で修正を行い、それを Main にチェリーピックしてください。新しいリリースタグを作成し、テスト検証を含むパイプラインを再実行します。このアプローチにより、Devの今後のリリースにも修正が含まれることが保証されます。

トレーサビリティのために、デプロイジョブの対象を対応する GitHub または Azure DevOps 環境に設定してください。リリースタグと解決済みコミットSHAを各デプロイ記録に含めて、どのバージョンが Test や Productionに到達したかを特定できるようにしましょう。Gitタグだけではバージョンのデプロイ先は記録できません。

オプション #2 を実装するために使用できるコンポーネントはどれですか?

Fabric-cicd - Microsoft Fabric ワークスペースで使用するために設計された Python ライブラリ。このライブラリは、コードファーストの継続的インテグレーション/継続的配置 (CI/CD) 自動化をサポートし、ワークスペースをデプロイフレームワークにシームレスに統合します。完全なエンドツーエンドの例については、 fabric-cicd と Azure DevOps のチュートリアルに従ってください。 fabric-cicdは2つの公開モードをサポートしています：
- アイテム定義API(デフォルト):Fabricの「アイテム作成」と「アイテム定義更新」APIを使って、アイテムを1つずつ公開します。
- バルクインポート(実験的): Bulk Import Item Definitions APIを用いて、すべてのアイテムを1回の呼び出しで公開します。このモードを使用するには、 enable_experimental_features と enable_bulk_publish 機能フラグを有効にしてください。詳細はfabric-cicd bulk publishをご覧ください。
Bulk-Import-Item-Definitions-API - API は、新しい項目の作成と既存の項目の更新の両方をサポートします。一方、Fabric の組み込みの依存関係処理に依存して、項目が正しい順序でデプロイされるようにします。これにより、手動による介入なしで、テスト環境と運用環境への一貫性のある反復可能なデプロイが可能になります。サンプルチュートリアルについては、 Fabric CI/CD と一括インポート項目定義 API に従ってください。

どのようなときにオプション 2 の使用を検討するか

デプロイ前にアイテム定義の環境特有のパラメータ化が必要な場合。ファブリックCICDパラメータ化機能は、各ステージごとに別々のアイテム定義を維持せずに、接続IDやレイクハウス IDを含む各ターゲット環境の値をparameter.ymlファイルで置き換えます。検索・置換操作、JSONパスで選択された値の置換、ターゲットワークスペースアイテムIDの動的解決をサポートしています。この機能は、ファブリックCICDを使用した場合のオプション1でも利用可能です。 git統合だけではこのデプロイ時の置換は提供されません。
信頼できる唯一の情報源として、またすべてのデプロイの origin として Git を使用したいとき。
各リリースにどの変更を含めるかを選択し、タグ付けされテスト済みのバージョンを本番環境にデプロイしたい場合。

オプション 3 - Fabric デプロイパイプラインを使用してデプロイする

このオプションを選択する場合、Git が接続されるのは Dev ステージまでです。 Dev ステージ以降、デプロイは Dev/Test/Prod のワークスペースの間で直接行われ、これには Fabric デプロイパイプラインが使用されます。 Fabric UIから直接ステージ間でデプロイすることも、デプロイメントパイプラインAPIを使ってAzureリリースパイプラインやGitHubワークフローの一環としてデプロイをオーケストレーションできます。これらの API を使用すると、チームは、自動テスト (ワークスペース内または Dev ステージの前に実行可能) や承認などを使用して、他のオプションと同様の "ビルド" と "リリース" のプロセスを構築できるようになります。

展開に特定の注文や関連項目、またはアクションが必要な場合は、段階間の展開に展開計画を付与できます。デプロイメントルールと自動バインディングは、ステージ固有の構成管理を引き続き行っています。

Devワークスペースに接続されたブランチにPRを承認してマージするとき:

Fabric UIまたはFabric Git APIsを使ってGitからDev workspaceを更新してください。必要なアップデート後の操作やテストを実行してください。
Fabric の UI またはデプロイパイプライン API を通じて Fabric のデプロイパイプラインを使用し、Dev から Test に変更をデプロイしてください。変更を本番に昇格する前に、テストで自動または手動テストを実行してください。
テストが通過しリリースマネージャーが承認したら、検証済みコンテンツを Test から本番環境へデプロイしてください。検証してから Prod へのデプロイまでの間に、Test で選択したコンテンツを再度テストせずに更新しないでください。

これらのステップはFabric UIから行うか、Azure PipelinesやGitHub ActionsのAPIで自動化できます。 UIベースのワークフローには外部のビルド・リリースパイプラインは必要ありません。

どのようなときにオプション 3 の使用を検討するか

チームが Fabric の組み込みのデプロイ機能を好み、その機能がデプロイのニーズを満たしている場合。 Fabric UIからワークスペース間を展開でき、外部リリースパイプラインを維持せずに済み、必要に応じてAPIを使って自動化できます。このアプローチは、Azure PipelinesやGitHub ActionsなどのDevOpsツールの経験が限られているチームにも適しています。
ソース管理を開発目的にのみ使用していて、変更をリリースパイプラインのステージ間で直接デプロイしたいとき。
デプロイルール、自動バインド、その他の使用可能な API だけで、リリースパイプラインのステージ間の構成を十分に管理できるとき。
Fabric デプロイパイプラインの他の機能 (Fabric での変更の表示、デプロイ履歴など) を使用したいとき。
また、Fabric デプロイパイプラインでのデプロイは線形構造であることと、パイプラインの作成と管理には他のアクセス許可が必要であることを考慮してください。

オプション 4 - Fabric 内の ISV 向け CI/CD (複数の顧客またはソリューションの管理)

このオプションは、他のものとは異なります。 Fabric 上に顧客向け SaaS アプリケーションを構築する独立系ソフトウェアベンダー (ISV) に最も適しています。通常、ISV は顧客ごとに別のワークスペースを用意しますが、ワークスペースの数は数百から数千に及ぶこともあります。各顧客に提供する分析の構造がよく似ていて、カスタマイズが不要な場合は、開発とテストのプロセスを一元化して Prod ステージでのみ各顧客に分割することをお勧めします。

この選択肢はオプション#2に基づいています:

開発者は Dev ブランチと Dev ワークスペースで作業し、オプション#2で説明されているように Dev から Mainにリリースしたい変更を選び出します。
Mainで選択したコミットにリリースタグを作成してプッシュします。たとえば v1.5.0 です。タグはGitHub ActionsのワークフローやAzure DevOpsのパイプラインをトリガーします。
パイプラインはタグをコミットSHAに対応付け、両方を記録し、ユニットテストを実行し、共有 Test のタグ付けされた定義を調整します。オプション #2で説明されているように、fabric-cicdまたはBulk Import Item Definitions APIを使用してそれらを展開します。デプロイ後は自動または手動テストを実施してください。検証が失敗したら、プロモーションを停止し、Devで問題を修正し、修正をMainに持ち込み、新しいタグを作成して次の実行に使います。
検証が成功し、設定された本番承認が下りたら、同じタグと記録されたコミットSHAを各顧客の本番ワークスペースに展開します。展開前または展開後にAPIを通じて顧客固有のパラメータや接続を適用してください。独立した顧客向けデプロイは並行して実行可能です。タグ、コミットSHA、顧客ターゲットを環境のデプロイ履歴に記録し、各顧客のデプロイされたバージョンを追跡可能にします。

どのようなときにオプション 4 の使用を検討するか

Fabric を基盤としてアプリケーションを構築している ISV である。
アプリケーションのマルチテナントを管理するために顧客ごとに異なるワークスペースを使用している
分離を確実にする、または顧客ごとに固有のテストを行うには、マルチテナントを Dev または Test という初期のステージで取り入れることをお勧めします。その場合、マルチテナントを使用するために必要なワークスペース数が大幅に増加することを考慮してください。

まとめ

この記事では、自動化された CI/CD プロセスを Fabric で構築したいチーム向けに、主な CI/CD オプションをまとめました。ここでは 4 つのオプションの概要を説明しますが、実際の制約とソリューションアーキテクチャによっては、ハイブリッドオプションや、まったく異なるものに適している可能性があります。この記事は、さまざまなオプションとその構築方法の案内として利用できますが、これらのオプションのいずれかのみを選択する必要はありません。

シナリオまたは特定の項目によっては制限事項があり、それらのシナリオを採用できない場合があります。

ツールについても同様です。ここではさまざまなツールについて触れていますが、同じレベルの機能を備える他のツールを選択することもできます。 Fabric と簡単に統合できるツールがある一方で、選択によっては、制限が増え、別の回避策が必要になるものもあることを考慮してください。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-10-19