Microsoft Fabric の Data Factory パイプライン用の CI/CD

[アーティクル]
12/03/2024

Fabric Data Factory では、継続的インテグレーションと継続的開発 (CI/CD) によって、コード変更の統合、テスト、デプロイが自動化され、効率的で信頼性の高い開発が保証されます。

Fabric では現在、アプリケーションライフサイクル管理 (ALM) チームとの共同作業の下、Git 統合とデプロイパイプラインという 2 つの機能がサポートされています。これらの機能を使用すると、ユーザーは個々の更新と共にワークスペースリソースをインポート/エクスポートすることができます。

Fabric Data Factory CI/CD ソリューションは、ARM テンプレートのエクスポート手法を使用したファクトリ全体の更新が推奨される Azure Data Factory モデルから逸脱しています。この手法の変更により、お客様はファクトリ全体を一時停止することなく、更新するパイプラインを選択的に選択できます。 Git 統合 (独自の Git 持ち込み) と展開パイプライン (組み込みの CI/CD) の両方で、1 つの環境に関連付けられた 1 つのワークスペースの概念が使用されます。開発、テスト、運用など、さまざまな環境に異なるワークスペースをマップする必要があります。

開発者が CI/CD を使用する理由

CI/CD は、ソフトウェアの配信を自動化するプラクティスであり、いくつかの重要な問題点を解決します。

手動による統合の問題: CI/CD がなければ、コードの変更を手動で統合すると、競合やエラーが発生し、開発が遅れるおそれがあります。
開発の遅延: 手動によるデプロイは時間がかかり、エラーが発生しやいため、新しい機能や更新の提供が遅れる原因になります。
一貫性のない環境: 環境 (開発、テスト、運用) が異なると、不整合が発生し、デバッグが困難な問題が発生するおそれがあります。
可視性の欠如: CI/CD がなければ、変更を追跡し、コードベースの状態を把握することが困難になるおそれがあります。

CI/CD、Git、デプロイパイプラインについて

CI/CD は、継続的インテグレーションと継続的デプロイで構成されます。

継続的インテグレーション (CI)

開発者は、Git で管理されるメインブランチに頻繁にコミットし、統合のために自動テストとビルドをトリガーします。 Git で変更が追跡され、新しいコミットの自動フェッチと自動テストが有効になります。

継続的デプロイ (CD)

デプロイパイプライン内の構造化されたデプロイステージを通じて、運用環境の開発に検証済みの変更をデプロイすることに重点を置いています。

Data Factory パイプラインとの Git 統合

Git はバージョン管理システムであり、開発者がコードベース (パイプラインの場合は JSON コード定義) の変更を追跡し、他のユーザーと共同作業できるようにします。一元化されたリポジトリが提供され、コードの変更はここに格納され、管理されます。 Fabric では現在、GitHub または Azure DevOps を介して Git がサポートされています。 Git を使用する際に理解する必要がある重要なワークフローがいくつかあります。

メインブランチ: メインブランチ ("マスターブランチ" と呼ばれる場合もあります) には、運用環境に対応したコードが保持されています。
機能ブランチ: これらのブランチはメインブランチとは別個のもので、開発を分離して、メインブランチを変更せずに開発できるようにします。
プル要求 (PR): PR を使用すると、ユーザーは、統合前に変更の提案、レビュー、議論を行うことができます。
マージ: これは、変更が承認されたときに発生します。 Git でこれらの変更が統合され、プロジェクトが継続的に更新されます。

Git 用のデプロイパイプライン

デプロイパイプラインは、Git と緊密に統合されています。開発者がコード変更を Git リポジトリにプッシュすると、CI/CD パイプラインがトリガーされます。この統合により、最新のコード変更が常にテストされ、自動的にデプロイされます。

ステージとジョブ

デプロイパイプラインは、複数のステージと各ステージ内のジョブで構成されます。通常、これらのステージは、開発 (コードのコンパイル)、テスト (テストの実行)、運用 (アプリケーションのデプロイ) の 3 つの環境に分けられます。パイプラインはこれらの各ステージを通過し、コードの徹底的なテストとデプロイが制御された方法で確実に行われるようにします。

自動化されたワークフロー

デプロイパイプラインによって、コードのビルド、テスト、デプロイのプロセス全体が自動化されます。この自動化により、人為的なエラーの削減と開発プロセスの迅速化が実現し、コード変更が一貫した信頼性の高い方法で運用環境に確実に提供されます。

Data Factory パイプラインの Git 統合を開始する

Data Factory パイプラインの Git 統合を設定するには、次の手順を実行します。

Git 統合の前提条件

Microsoft Fabric ワークスペースを使用して Git にアクセスするには、以下の Fabric と Git の両方に関する前提条件について確認してください。

Power BI Premium ライセンスか Fabric 容量のどちらか。
管理ポータルから以下のテナントスイッチを有効化済み。
Azure DevOps または GitHub のいずれかのアカウント。
- Azure DevOps アカウントの場合:
  - Fabric ワークスペースを使用している同じユーザーに登録されているアクティブな Azure アカウント。無料アカウントを作成します。
  - 既存のリポジトリへのアクセス
- GitHub アカウントの場合:
  - アクティブな GitHub アカウント。無料アカウントを作成します。
  - "コンテンツ" に対するリポジトリアクセス許可での "読み取り" および "書き込み" アクセス許可を持つ粒度の細かいトークン、またはレポジトリスコープで有効な GitHub クラシックトークン。

手順 1: Git リポジトリに接続する

Fabric の Data Factory パイプラインで Git 統合を使用するには、以下で説明するように、まず Git リポジトリに接続する必要があります。

Fabric にサインインし、Git へ接続させたいワークスペースに移動します。
[ワークスペースの設定] を選択します。
[Git 統合] を選択します。
Git プロバイダーを選択します。現在、Fabric でサポートされているのは Azure DevOps または GitHub だけです。 GitHub を使用する場合は、[アカウントの追加] を選択して GitHub アカウントを接続する必要があります。サインインした後、接続を選択して、Fabric が GitHub アカウントにアクセスできるようにします。

手順 2: ワークスペースに接続する

Git リポジトリに接続したら、以下で説明するようにワークスペースに接続する必要があります。

ドロップダウンメニューから、接続するブランチに関する以下の詳細情報を指定します。
1. Azure DevOps ブランチ接続の場合は、以下の詳細を指定します。
  - 組織: Azure DevOps 組織名。
  - プロジェクト: Azure DevOps プロジェクト名。
  - リポジトリ: Azure DevOps リポジトリ名。
  - ブランチ: Azure DevOps ブランチ名。
  - フォルダー: Azure DevOps フォルダー名。
2. GitHub ブランチ接続の場合は、以下の詳細を指定します。
  - リポジトリ URL: GitHub リポジトリの URL。
  - ブランチ: GitHub ブランチ名。
  - フォルダー: GitHub フォルダー名。
[接続と同期] を選択します。
接続が完了すると、ワークスペースにソース管理に関する情報が表示され、それによってユーザーは接続されたブランチ、ブランチ内の各アイテムの状態、最後の同期時刻を確認できます。

手順 3: Git に変更をコミットする

Git リポジトリとワークスペースに接続すると、ここで説明するように、Git に変更をコミットできます。

ワークスペースに移動します。
[ソース管理] アイコンを選びます。このアイコンは、コミットされていない変更の数を示します。
[ソース管理] パネルから [変更] タブを選択します。変更したすべての項目と、状態を示すアイコン (新規、変更済み、競合、または 削除済み) を含む一覧が表示されます。
コミットする項目を選択します。すべての項目を選択するには、上部のボックスにチェックを入れます。
"(省略可能)" ボックスにコミットコメントを追加します。
[コミット] を選択します。

変更がコミットされると、コミットされた項目はリストから削除され、ワークスペースは同期先の新しいコミットを指すようになります。

手順 4: ("省略可能") Git からワークスペースを更新する

ワークスペースに移動します。
[ソース管理] アイコンを選びます。
[ソース管理] パネルで [更新] を選択します。前回の更新以降に Git 接続ソースからブランチで変更されたすべての項目を含む一覧が表示されます。
[すべて更新] を選択します。

更新が正常に完了すると、項目の一覧が削除され、ワークスペースは同期先の新しいコミットを指すようになります。

Git 用のデプロイパイプラインの使用を開始する

以下の手順を実行して、Fabric ワークスペースで Git デプロイパイプラインを使用します。

デプロイパイプラインの前提条件

作業を開始する前に、必ず以下の前提条件を設定してください。

アクティブな Microsoft Fabric サブスクリプション。
Fabric ワークスペースの管理者アクセス。

手順 1: デプロイパイプラインを作成する

[ワークスペース] ポップアップから、[デプロイパイプライン] を選択します。
[パイプラインの作成] または [+ 新しいパイプライン] を選択します。

手順 2: パイプラインに名前を付けてステージを割り当てる

[デプロイパイプラインの作成] ダイアログボックスで、パイプラインの名前と説明を入力して、[次へ] を選びます。
展開パイプラインに必要なステージを定義して、展開パイプラインの構造を設定します。既定では、パイプラインには "開発"、"テスト"、"運用" という 3 つのステージがあります。

別のステージを追加したり、ステージを削除したり、ボックスに新しい名前を入力して名前を変更したりできます。完了したら、[作成] (または [作成して続行]) を選択します。

手順 3: ワークスペースをデプロイパイプラインに割り当てる

パイプラインを作成したら、管理したいコンテンツをパイプラインに追加する必要があります。パイプラインにコンテンツを追加するには、パイプラインステージにワークスペースを割り当てます。ワークスペースはどのステージにも割り当てることができます。指示に従ってワークスペースをパイプラインに割り当てます。

手順 4: 空のステージにデプロイする

あるパイプラインステージでのコンテンツの作業が完了したら、それを次のステージにデプロイできます。デプロイパイプラインには、コンテンツのデプロイに関して次の 3 つのオプションが用意されています:
- 完全なデプロイ: すべてのコンテンツをターゲットステージにデプロイします。
- 選択的デプロイ: どのコンテンツをターゲットステージにデプロイするかを選択します。
- 逆方向デプロイ: パイプライン内の後方のステージから前方のステージに向かってコンテンツをデプロイします。現在、逆方向のデプロイは、ターゲットステージが空の (ワークスペースが割り当てされていない) 場合にのみ可能です。
コンテンツのデプロイ方法を選択したら、デプロイを確認しメモを残すことができます。

手順 5: あるステージから別のステージにコンテンツをデプロイする

パイプラインステージにコンテンツを含めたら、次のステージのワークスペースにコンテンツが含まれている場合でも、次のステージに配置できます。ペアになっている項目は上書きされます。このプロセスの詳細については、「既存ワークスペースへのコンテンツのデプロイ」セクションで確認できます。
デプロイ履歴を調べて、各ステージにコンテンツが最後にデプロイされた時刻を確認できます。デプロイする前に 2 つのパイプラインの違いを確認するには、「異なるデプロイステージのコンテンツの比較」を参照してください。

既知の制限事項

Microsoft Fabric の Data Factory パイプライン用の CI/CD には、以下の既知の制限事項が適用されます。

ワークスペース変数: CI/CD では現在、ワークスペース変数はサポートされていません。
Git 統合のサポートの制限: 現時点で Fabric でサポートされているのは、Azure DevOps と GitHub を使用した Git 統合だけです。 GitHub による Git 統合にはより多くの制限が存在するため、Azure DevOps による Git 統合が推奨されます。
OAuth コネクタを使用したパイプラインアクティビティ: MS Teams および Outlook コネクタの場合、上位環境にデプロイするには、ユーザーが各パイプラインを手動で開き、各アクティビティにサインインする必要があります。これは現在の制限事項です。
データフローを呼び出すパイプライン: データフローを呼び出すパイプラインが昇格された場合でも、前のワークスペースのデータフローが参照されます。これは正しくありません。この動作は、データフローがデプロイパイプラインで現在サポートされていないために発生します。

次の方法で共有

Microsoft Fabric の Data Factory パイプライン用の CI/CD

開発者が CI/CD を使用する理由