この記事の目的は、一般的な顧客シナリオに基づき、Fabric で CI/CD プロセスを構築するためのさまざまなオプションを、Fabric 開発者に示すことです。 この記事では、CI/CD プロセスの "継続的デプロイ" (CD) に特に注目します。 "継続的インテグレーション" (CI) 部分の説明については、Git ブランチの管理に関するページを参照してください。
この記事では、さまざまな独立したオプションの概要を説明していますが、多くの組織ではハイブリッド アプローチが採用されています。
前提条件
この記事のオプションを使用して CI/CD プロセスを構築するには、次のものが必要です。
Fabric ワークスペース (展開を構成するにはワークスペース管理者である必要があります)
Git ベースのオプション (1、2、4) の場合、サポートされている Git プロバイダー (Azure DevOpsまたはGitHub) が Git 統合によって接続されています
Note
オプション 3 では、Fabric のデプロイ パイプラインを使用します。 このオプションを使用するには、デプロイ パイプライン機能へのアクセスと 、パイプライン を作成および管理するためのアクセス許可も必要です。
開発プロセス
開発プロセスはどのデプロイ シナリオでも同じであり、新しい更新プログラムを運用環境にリリースする方法とは無関係です。 開発者がソース管理を使用するときは、分離された環境で作業する必要があります。 Fabric では、その環境はローカル コンピューター上の IDE (Power BI Desktop、VS Code など) でも、Fabric 内の別のワークスペースでもかまいません。 開発プロセスに関するさまざまな考慮事項については、Git ブランチの管理に関するページを参照してください
リリース プロセス
リリース プロセスが始まるのは、新しい更新プログラムが完成して pull request (PR) がチームの共有ブランチ (Main、Dev など) にマージされたときです。 この時点以降、Fabric でリリース プロセスを構築するには、さまざまなオプションがあります。
次の表は、選択に役立つオプションをまとめたものです。 多くのチームが複数のチームを組み合わせています。
| オプション | 真実の源 | 分岐戦略 | 展開のメカニズム | ステージごとの構成 | 最適な用途 |
|---|---|---|---|---|---|
| 1 - Git 統合 | Git | Gitflow (ステージごとのプライマリ ブランチ) |
Fabric Git API (update-from-git) |
ステージごとのブランチを分離する | Git を単一の信頼できるソースとして必要とし、Gitflow に従うチーム |
| 2 - Fabric アイテム API | Git（単一のMainブランチ）¹ | トランクベース | Fabric Items API (fabric-cicd または一括インポート項目定義 API) | ビルド環境用スクリプト | 展開前に項目定義を変換する必要があるトランクベースのチーム |
| 3 - デプロイ パイプライン | Fabric ワークスペース（dev 経由の Git のみ） | トランクベース | デプロイ パイプライン API | 展開規則と自動バインド | ワークスペース間での Fabric ネイティブなローコード展開を好むチーム |
| 4 - ISV 向け CI/CD | Git（単一のメイン ブランチ） | トランクベース | Fabric Items API (顧客ワークスペースごと) | 顧客ごとのリリース パラメーター | 顧客ごとの多くのワークスペースを管理する ISV |
¹ オプション 2 では、ステージ ワークスペース ( テスト と Prod を含む) は Git に接続されていません。 項目定義は、Main ブランチの Fabric Items API を介してそれらにプッシュされます。
オプション 1 - Git 統合を使用した定義ベースのデプロイ
このオプションでは、すべてのデプロイが Git リポジトリを origin としています。 リリース パイプラインの各ステージに専用のプライマリ ブランチがあり (このダイアグラムでは、Dev、Test、Prod というステージ)、ここから Fabric 内の適切なワークスペースにフィードされます。
Dev ブランチに対する PR が承認され、マージされると、次のことが行われます。
- リリースパイプラインは 開発 ワークスペースの内容を更新します。 このプロセスにはユニットテストを実行するためのビルドパイプラインも含まれますが、実際のファイルのアップロードはリポジトリからFabric Git APIを使って直接ワークスペースにアップロードされます。 このワークスペースの特定の設定やデータ取り込みのために、他のFabric APIを展開後の操作で呼び出す必要があるかもしれません。 一部のアイテム依存関係は新しいワークスペースに同期されると論理IDを介して自動的にバインドされますが、他のものはこれらのデプロイ後の更新が必要です。 詳細は「 クロスワークスペース展開における依存関係バインディングの理解」を参照してください。
- 次に、Test ブランチに対する PR が作成されます。 ほとんどの場合、PR はリリース ブランチを使用して作成されます。ここで、次のステージに進むコンテンツを厳選できます。 この PR には、チームまたは組織内の他のプロセスと同じレビューと承認のプロセスを含めるようにします。
- 別の "ビルド" および "リリース" パイプラインがトリガーされます。この目的は Test ワークスペースを更新することであり、これには最初のステップで説明したものと同様のプロセスが使用されます。
- Prod ブランチに対する PR が作成されます。これにはステップ 2 で説明したものと同様のプロセスが使用されます。
- 別の "ビルド" および "リリース" パイプラインがトリガーされます。この目的は Prod ワークスペースを更新することであり、これには最初のステップで説明したものと同様のプロセスが使用されます。
どのようなときにオプション 1 の使用を検討するか
- 信頼できる唯一の情報源として、またすべてのデプロイの origin として Git リポジトリを使用したいとき。
- チームがブランチ戦略として Gitflow に従っているとき (複数プライマリ ブランチを含む)。
- リポジトリからのアップロードが直接ワークスペースにデプロイされる (デプロイ前にファイルに変更を加える "ビルド環境" を必要としていないとき)。 これを変更するには、デプロイ後に API を呼び出すか、ワークスペースの項目を実行します。
オプション 2 - Fabric Items API を使用した定義ベースのデプロイ
このオプションを使うと、すべてのデプロイメントはGitリポジトリの同じブランチ(メイン)から送信されます。 リリースパイプラインの各段階には独自の ビルド および リリース パイプラインがあります。 これらのパイプラインは ビルド環境 を使ってユニットテストやスクリプトを実行し、アイテムの定義を修正してからワークスペースにアップロードすることがあります。 たとえば、適切なステージに合わせて構成を調整するために、データ ソース接続、ワークスペース内の項目間の接続、またはパラメーターの値を変更する場合があります。 すべてのアイテム依存関係がこれらの変更を必要とするわけではありません。新しいワークスペースにデプロイされると論理IDを通じて自動的にバインドされるものもあります。 どの依存関係が自動的にバインドされ、どれが手動でパラメータ化が必要かを理解するには、「 クロスワークスペース展開における依存関係バインディングの理解」を参照してください。
Dev ブランチに対する PR が承認され、マージされると、次のことが行われます。
- Dev ステージ用に新しいビルド環境を構築して単体テストを実行する "ビルド" パイプラインがトリガーされます。 次に、"リリース" パイプラインがトリガーされます。この目的はコンテンツをビルド環境にアップロードし、スクリプトを実行して構成の一部を変更し、この構成を Dev ステージに合わせて調整し、Fabric の項目定義の更新 API を使用してファイルをワークスペースにアップロードすることです。
- このプロセス (データの取り込みとリリース マネージャーからの承認も含まれます) が完了したら、次の "ビルド" および "リリース" パイプラインを Test ステージ用に作成できます。 これらのステージは、最初のステップで説明したものと同様のプロセスで作成されます。 Test ステージでは、その他の自動または手動テストがデプロイ後に必要になる可能性があります。その目的は、変更を Prod ステージにリリースする準備ができているかどうかを検証することです。
- すべての自動および手動テストが完了したら、リリース マネージャーは "ビルド" および "リリース" パイプラインを承認し、Prod ステージに進むことができます。 通常、Prod ステージは Test/Dev ステージとは構成が異なるため、デプロイ後に変更をテストすることも重要です。 コンシューマーが利用できなくなる可能性を最小限に抑えるためには、変更に基づくデプロイによって追加のデータインジェストがトリガーされる必要があります。
オプション #2 を実装するために使用できるコンポーネントはどれですか?
- Fabric-cicd - Fabricワークスペース用に設計されたPythonライブラリ。 このライブラリは、コードファーストの継続的インテグレーション/継続的配置 (CI/CD) 自動化をサポートし、ワークスペースをデプロイ フレームワークにシームレスに統合します。 完全なエンド ツー エンドの例については、 fabric-cicd と Azure DevOps のチュートリアルに従ってください。
- Bulk-Import-Item-Definitions-API - API は、新しい項目の作成と既存の項目の更新の両方をサポートします。一方、Fabric の組み込みの依存関係処理に依存して、項目が正しい順序でデプロイされるようにします。 これにより、手動による介入なしで、テスト環境と運用環境への一貫性のある反復可能なデプロイが可能になります。 サンプル チュートリアルについては、 Fabric CI/CD と一括インポート項目定義 API に従ってください。
どのようなときにオプション 2 の使用を検討するか
- 信頼できる唯一の情報源として、またすべてのデプロイの origin として Git を使用したいとき。
- チームがブランチ戦略としてトランクベースワークフローを採用している場合。
- デプロイの前にワークスペース固有の属性 (たとえば connectionId や lakehouseId) に (カスタム スクリプトを使用して) 変更を加えるビルド環境が必要である。
- Fabric 項目の作成、更新、または削除のために、項目のコンテンツを Git から取得して対応する Fabric 項目 API を呼び出すリリース パイプライン (カスタム スクリプト) が必要である。
オプション 3 - Fabric デプロイ パイプラインを使用してデプロイする
このオプションを選択する場合、Git が接続されるのは Dev ステージまでです。 Dev ステージ以降、デプロイは Dev/Test/Prod のワークスペースの間で直接行われ、これには Fabric デプロイ パイプラインが使用されます。 ツール自体は Fabric の内部にありますが、開発者はデプロイ パイプライン API を使用してデプロイのオーケストレーションを自分の Azure リリース パイプラインの一部として、または GitHub ワークフローとして行うことができます。 これらの API を使用すると、チームは、自動テスト (ワークスペース内または Dev ステージの前に実行可能) や承認などを使用して、他のオプションと同様の "ビルド" と "リリース" のプロセスを構築できるようになります。
main ブランチに対する PR が承認され、マージされると、次のことが行われます。
- Fabric Git API を使用して変更を Dev ステージにアップロードする "ビルド" パイプラインがトリガーされます。 必要に応じて、このパイプラインで他の API をトリガーして、Dev ステージでのデプロイ後操作またはテストを開始できます。
- Dev のデプロイが完了すると、変更を Dev ステージから Test ステージにデプロイするリリース パイプラインが開始されます。 デプロイ後は自動および手動テストを実行し、変更を十分にテストした上で運用環境に反映するようにします。
- テストが完了し、リリース マネージャーが Prod ステージへのデプロイを承認すると、Prod へのリリースが開始され、デプロイが完了します。
どのようなときにオプション 3 の使用を検討するか
- ソース管理を開発目的にのみ使用していて、変更をリリース パイプラインのステージ間で直接デプロイしたいとき。
- デプロイ ルール、自動バインド、その他の使用可能な API だけで、リリース パイプラインのステージ間の構成を十分に管理できるとき。
- Fabric デプロイ パイプラインの他の機能 (Fabric での変更の表示、デプロイ履歴など) を使用したいとき。
- また、Fabric デプロイ パイプラインでのデプロイは線形構造であることと、パイプラインの作成と管理には他のアクセス許可が必要であることを考慮してください。
オプション 4 - Fabric 内の ISV 向け CI/CD (複数の顧客またはソリューションの管理)
このオプションは、他のものとは異なります。 Fabric 上に顧客向け SaaS アプリケーションを構築する独立系ソフトウェア ベンダー (ISV) に最も適しています。 通常、ISV は顧客ごとに別のワークスペースを用意しますが、ワークスペースの数は数百から数千に及ぶこともあります。 各顧客に提供する分析の構造がよく似ていて、カスタマイズが不要な場合は、開発とテストのプロセスを一元化して Prod ステージでのみ各顧客に分割することをお勧めします。
このオプションは、オプション 2 に基づいています。 main に対する PR が承認され、マージされると、次のことが行われます。
- Dev ステージ用に新しい "ビルド環境" を構築し、単体テストを実行する "ビルド" パイプラインがトリガーされます。 テストが完了すると、"リリース" パイプラインがトリガーされます。 このパイプラインでは、コンテンツを "ビルド" 環境にアップロードし、スクリプトを実行して構成の一部を変更し、この構成を Dev ステージに合わせて調整してから、Fabric の項目定義の更新 API を使用してファイルをワークスペースにアップロードすることができます。
- このプロセス (データの取り込みとリリース マネージャーからの承認も含まれます) が完了したら、Test ステージ用の次の "ビルド" と "リリース" のパイプラインを開始できます。 このプロセスは、最初のステップで説明したものに似ています。 Test ステージでは、デプロイ後に他の自動または手動テストが必要になることがあります。その目的は、高い品質で変更を Prod ステージにリリースする準備ができているかどうかを検証することです。
- すべてのテストに合格して承認プロセスが完了すると、Prod の顧客へのデプロイを開始できます。 顧客ごとに専用のリリースと独自のパラメーターがあるため、それぞれの固有の構成とデータ接続は関連する顧客のワークスペース内で行うことができます。 構成の変更は、"ビルド" 環境内でスクリプトを使用して行うか、デプロイ後に API を使用して行うことができます。 すべてのリリースは、互いに関連も依存もしていないため、並列で実行できます。
どのようなときにオプション 4 の使用を検討するか
- Fabric を基盤としてアプリケーションを構築している ISV である。
- アプリケーションのマルチテナントを管理するために顧客ごとに異なるワークスペースを使用している
- 分離を確実にする、または顧客ごとに固有のテストを行うには、マルチテナントを Dev または Test という初期のステージで取り入れることをお勧めします。 その場合、マルチテナントを使用するために必要なワークスペース数が大幅に増加することを考慮してください。
まとめ
この記事では、自動化された CI/CD プロセスを Fabric で構築したいチーム向けに、主な CI/CD オプションをまとめました。 ここでは 4 つのオプションの概要を説明しますが、実際の制約とソリューション アーキテクチャによっては、ハイブリッド オプションや、まったく異なるものに適している可能性があります。 この記事は、さまざまなオプションとその構築方法の案内として利用できますが、これらのオプションのいずれかのみを選択する必要はありません。
シナリオまたは特定の項目によっては制限事項があり、それらのシナリオを採用できない場合があります。
ツールについても同様です。 ここではさまざまなツールについて触れていますが、同じレベルの機能を備える他のツールを選択することもできます。 Fabric と簡単に統合できるツールがある一方で、選択によっては、制限が増え、別の回避策が必要になるものもあることを考慮してください。