最適な Fabric CI/CD ワークフロー オプションを選択する
この記事の目的は、一般的な顧客シナリオに基づき、Fabric で CI/CD プロセスを構築するためのさまざまなオプションを、Fabric 開発者に示すことです。 この記事では、CI/CD プロセスの "継続的デプロイ" (CD) に特に注目します。 "継続的インテグレーション" (CI) 部分の説明については、Git ブランチの管理に関するページを参照してください。
この記事では、さまざまな独立したオプションの概要を説明していますが、多くの組織ではハイブリッド アプローチが採用されています。
前提条件
展開パイプライン機能にアクセスするには、次の条件を満たす必要があります:
Microsoft Fabric サブスクリプションをお持ちの場合
自分が Fabric ワークスペースの管理者である
開発プロセス
開発プロセスはどのデプロイ シナリオでも同じであり、新しい更新プログラムを運用環境にリリースする方法とは無関係です。 開発者がソース管理を使用するときは、分離された環境で作業する必要があります。 Fabric では、その環境はローカル コンピューター上の IDE (Power BI Desktop、VS Code など) でも、Fabric 内の別のワークスペースでもかまいません。 開発プロセスに関するさまざまな考慮事項については、Git ブランチの管理に関するページを参照してください
リリース プロセス
リリース プロセスが始まるのは、新しい更新プログラムが完成して pull request (PR) がチームの共有ブランチ (Main、Dev など) にマージされたときです。 この時点以降、Fabric でリリース プロセスを構築するには、さまざまなオプションがあります。
オプション 1 - Git ベースのデプロイ
このオプションでは、すべてのデプロイが Git リポジトリを origin としています。 リリース パイプラインの各ステージに専用のプライマリ ブランチがあり (このダイアグラムでは、Dev、Test、Prod というステージ)、ここから Fabric 内の適切なワークスペースにフィードされます。
Dev ブランチに対する PR が承認され、マージされると、次のことが行われます。
- Dev ワークスペースのコンテンツを更新するリリース パイプラインがトリガーされます。 このプロセスには、単体テストを実行する "ビルド" パイプラインも含まれることがありますが、ファイルの実際のアップロードはリポジトリからワークスペースに直接、Fabric Git API を使用して行われます。 必要に応じて、このワークスペース専用の構成を設定するデプロイ後操作のために、またはデータの取り込みのために、その他の Fabric API を呼び出すこともあります。
- 次に、Test ブランチに対する PR が作成されます。 ほとんどの場合、PR はリリース ブランチを使用して作成されます。ここで、次のステージに進むコンテンツを厳選できます。 この PR には、チームまたは組織内の他のプロセスと同じレビューと承認のプロセスを含めるようにします。
- 別の "ビルド" および "リリース" パイプラインがトリガーされます。この目的は Test ワークスペースを更新することであり、これには最初のステップで説明したものと同様のプロセスが使用されます。
- Prod ブランチに対する PR が作成されます。これにはステップ 2 で説明したものと同様のプロセスが使用されます。
- 別の "ビルド" および "リリース" パイプラインがトリガーされます。この目的は Prod ワークスペースを更新することであり、これには最初のステップで説明したものと同様のプロセスが使用されます。
どのようなときにオプション 1 の使用を検討するか
- 信頼できる唯一の情報源として、またすべてのデプロイの origin として Git リポジトリを使用したいとき。
- チームがブランチ戦略として Gitflow に従っているとき (複数プライマリ ブランチを含む)。
- リポジトリからのアップロードが直接ワークスペースにデプロイされる (デプロイ前にファイルに変更を加える "ビルド環境" を必要としていないとき)。 これを変更するには、デプロイ後に API を呼び出すか、ワークスペースの項目を実行します。
オプション 2 - ビルド環境を使用する Git ベースのデプロイ
このオプションでは、すべてのデプロイが Git リポジトリの同じブランチ (Main) を origin としています。 リリース パイプラインの各ステージに専用の "ビルド" および "リリース" パイプラインがあります。 これらのパイプラインでは、ワークスペースへアップロードする前に "ビルド環境" を使用して、単体テストと、項目の定義の一部を変更するスクリプトを実行することがあります。 たとえば、適切なステージに合わせて構成を調整するために、データ ソース接続、ワークスペース内の項目間の接続、またはパラメーターの値を変更する場合があります。
Dev ブランチに対する PR が承認され、マージされると、次のことが行われます。
- Dev ステージ用に新しいビルド環境を構築して単体テストを実行する "ビルド" パイプラインがトリガーされます。 次に、"リリース" パイプラインがトリガーされます。この目的はコンテンツをビルド環境にアップロードし、スクリプトを実行して構成の一部を変更し、この構成を Dev ステージに合わせて調整し、Fabric の項目定義の更新 API を使用してファイルをワークスペースにアップロードすることです。
- このプロセス (データの取り込みとリリース マネージャーからの承認も含まれます) が完了したら、次の "ビルド" および "リリース" パイプラインを Test ステージ用に作成できます。 これらのステージは、最初のステップで説明したものと同様のプロセスで作成されます。 Test ステージでは、その他の自動または手動テストがデプロイ後に必要になる可能性があります。その目的は、変更を Prod ステージにリリースする準備ができているかどうかを検証することです。
- すべての自動および手動テストが完了したら、リリース マネージャーは "ビルド" および "リリース" パイプラインを承認し、Prod ステージに進むことができます。 通常、Prod ステージは Test/Dev ステージとは構成が異なるため、デプロイ後に変更をテストすることも重要です。 また、コンシューマーが使用できなくなる可能性を最小限に抑えるために、デプロイにより、変更に基づいてさらにデータのインジェストをトリガーする必要があります。
どのようなときにオプション 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 と簡単に統合できるツールがある一方で、選択によっては、制限が増え、別の回避策が必要になるものもあることを考慮してください。