Azure Data Factory のソース管理

適用対象: Azure Data Factory Azure Synapse Analytics

既定の Azure Data Factory ユーザー インターフェイス エクスペリエンス (UX) では、データ ファクトリに対して直接作成されます。 このエクスペリエンスには次のような制限があります。

• Data Factory サービスには、変更について JSON エンティティを格納するためのリポジトリが含まれていません。 変更を保存する唯一の方法は [すべて公開] ボタンを使用することであり、変更内容はすべて、Data Factory サービスに直接公開されます。
• Data Factory サービスは、コラボレーションとバージョン管理で最適化されていません。
• Data Factory 自体をデプロイするために必要な Azure Resource Manager テンプレートは含まれていません。

効率的に作成できるよう、Azure Data Factory では、Azure Repos または GitHub のいずれかで Git リポジトリを構成することができます。 Git はバージョン管理システムであり、変更追跡や共同作業を簡単にします。 この記事では、Git リポジトリを構成し、そこで作業する方法を簡単に説明し、ベスト プラクティスとトラブルシューティング ガイドを提示します。

また、「Azure Data Factory における継続的インテグレーションと継続的デリバリー (CI/CD)」を参照して、ソース管理が重要な側面となる、より大きな CI/CD パターンの詳細を確認することもできます。

Azure Data Factory を Git と統合する方法の詳細については、次の 15 分のチュートリアル ビデオをご覧ください。

Git 統合の利点

Git 統合が作成作業にもたらす利点をいくつか下の一覧にまとめています。

• ソース管理: データ ファクトリのワークロードの重要性が高まると、ソース管理に関して以下に示すような利点を活用するために、そのファクトリと Git を統合する必要性を感じることも出てきます。
  • 変更の追跡と監査の機能
  • バグの原因となっている変更を元に戻す機能
• 途中保存: データ ファクトリ サービスに対して作成するとき、変更内容を下書きとして保存することはできません。公開内容はすべて、データ ファクトリの妥当性確認に合格する必要があります。 パイプラインが完了していない場合、あるいは単純に、コンピューターがクラッシュして変更内容が失われては困るときに、Git 統合によって、データ ファクトリ リソースの状態に関係なく、データ ファクトリ リソースを増分方式で変更することができます。 Git リポジトリを構成すると、変更内容を保存できます。変更内容に満足できるまでテストしてから公開できます。
• コラボレーションと管理: 同じファクトリに複数のチーム メンバーが貢献している場合、コード レビューのプロセスを通じてチームメイトが相互に共同作業できるようにすることが必要な場合があります。 共同作成者ごとにアクセス許可を変えるようにファクトリを設定することもできます。 一部のチーム メンバーに Git 経由での変更のみを許可し、チーム内の特定のメンバーにファクトリの変更の公開を許可するとします。
• CI/CD の改善: 継続的デリバリー プロセスで複数の環境にデプロイしている場合、Git 統合で特定のアクションが簡単になります。 そうしたアクションの例を次に示します。
  • "開発" ファクトリに何か変更があった時点ですぐに自動でトリガーされるようにリリース パイプラインを構成します。
  • Resource Manager テンプレートのパラメーターとして利用可能なプロパティをファクトリ内でカスタマイズします。 これは、必要なプロパティのみをパラメーターにして、残りをすべてハード コーディングする場合に便利です。
• パフォーマンスの向上: Git 統合の平均的なファクトリでは、データ ファクトリ サービスに対し、作成が 1 つの場合に比べ、読み込み速度が 10 倍になります。 このパフォーマンスの向上は、リソースが Git 経由でダウンロードされることに起因します。

Git リポジトリに接続する

Azure Repos と GitHub の両方で Git リポジトリをデータ ファクトリに接続するには、4 つの方法があります。 Git リポジトリに接続した後、管理ハブの [ソース管理] セクションにある [Git 構成] で構成を表示し、管理することができます。

構成方法 1:ホーム ページ

Azure Data Factory のホームページで、上部にある [コード リポジトリの設定] を選択します。

構成方法 2:作成キャンバス

Azure Data Factory UX 作成キャンバスで、 [Data Factory] ドロップダウン メニューを選択し、 [Set up code repository](コード リポジトリの設定) を選択します。

構成方法 3:管理ハブ

Azure Data Factory Studio の管理ハブに移動します。 [ソース管理] セクションで [Git 構成] を選択します。 接続されているリポジトリがない場合は、[構成] を選択します。

構成方法 4:ファクトリの作成時

Azure portal で新しいデータ ファクトリを作成するときに、 [Git 構成] タブで Git リポジトリの情報を構成できます。

Azure Repos Git 統合を使用した作成

Azure Repos Git 統合を使ったビジュアルの作成では、データ ファクトリ パイプラインでの作業時にソース管理とコラボレーションがサポートされます。 ソース管理やコラボレーション、バージョン管理などで､データ ファクトリを Azure Repos Git 統合リポジトリに関連付けることができます。 各 Azure Repos Git 組織は複数のレポジトリを持つことができますが､1つの Azure Repos Git リポジトリに関連付けられるデータ ファクトリの数は 1 つだけです｡ Azure Repos アカウントまたはリポジトリがない場合は、こちらの手順に従ってリソースを作成します。

Azure Repos の設定

構成ペインでは、次のコード リポジトリの各設定を構成する手順について説明します。

リポジトリ設定の編集

構成した Azure Repos Git リポジトリの設定に調整を加える必要がある場合は、[編集] を選択できます。

発行ブランチを更新したり、ADF スタジオの発行ボタンを無効にするかどうかを決定したりできます。 スタジオの発行ボタンを無効にすることを選択すると、スタジオ内の発行ボタンが淡色表示になります。 こうすると、最後に自動発行されたデプロイが上書きされるのを回避する助けになります。

別の Microsoft Entra テナントを使用する

Azure Repos Git リポジトリは、別の Microsoft Entra テナントに配置できます。 別の Microsoft Entra テナントを指定するには、使用している Azure サブスクリプションの管理者のアクセス許可が必要です。 詳細については、サブスクリプション管理者の変更に関する記事を参照してください。

個人用の Microsoft アカウントを使用する

Git の統合に個人用の Microsoft アカウントを使用するには、Azure の個人用のリポジトリを組織の Active Directory にリンクできます。

1. 個人用の Microsoft アカウントを組織の Active Directory にゲストとして追加します。 詳細については、Azure portal での Microsoft Entra B2B コラボレーション ユーザーの追加に関するページを参照してください。

2. 個人用の Microsoft アカウントを使用して、Azure portal にサインインします。 その後組織の Active Directory に切り替えます。

3. Azure DevOps セクションに移動すると、個人用のリポジトリがあることを確認できます。 リポジトリを選択し、Active Directory に接続します。

これらの構成手順を実行すると、Data Factory UI で Git 統合を設定するときに個人用のリポジトリを使用できます。

Azure Repos を組織の Active Directory に接続する方法の詳細については、Microsoft Entra ID に Azure DevOps 組織を接続する方法に関するページを参照してください。

GitHub 統合での作成

GitHub 統合を使用したビジュアルの作成では、データ ファクトリ パイプラインの使用にあたりソース管理とコラボレーションがサポートされています。 データ ファクトリを GitHub account リポジトリと関連付けて、ソース管理、コラボレーション、バージョン管理などを行うことができます。 1 つの GitHub アカウントで複数のリポジトリをホストでき、各リポジトリを複数のデータ ファクトリに関連付けることができます。 同じリポジトリ内の別のブランチを使用するように各データ ファクトリを構成すると、構成を個別に管理しながら、個別の環境 (開発、ステージング、運用など) を維持できます。 GitHub アカウントまたはリポジトリがない場合は、こちらの手順に従ってリソースを作成します。

GitHub と Data Factory の統合では、パブリック GitHub (つまり https://github.com)、GitHub Enterprise Cloud、GitHub Enterprise Server がサポートされています。 GitHub のリポジトリの読み取りおよび書き込みアクセス許可があれば、パブリックおよびプライベートの両方の GitHub リポジトリを Data Factory で使用できます。 パブリック リポジトリに接続するには、[リポジトリ名] のドロップダウン メニューに表示されないため、[リンク リポジトリ オプションを使用する] を選択します。 ADF の GitHub エンタープライズ サーバー統合は、公式にサポートされているバージョンの GitHub エンタープライズ サーバーでのみ機能します。

GitHub Organization アカウントで所有するリポジトリの場合、管理者は ADF アプリを承認する必要があります。 GitHub ユーザー アカウントで所有するリポジトリの場合、コラボレーター アクセス許可以上を持つユーザーは ADF アプリを承認できます。 この権限は ADF アプリからアカウントまたは Organization が所有するすべてのリポジトリへの直接アクセスが許可されるものではなく、ユーザーに代わって、ユーザーのアクセス許可に基づき、ADF アプリからリポジトリへのアクセスが可能になるのみです。

GitHub の設定

[構成] ウィンドウには、次の GitHub リポジトリの設定が表示されます。

リポジトリ設定の編集

構成した GitHub リポジトリの設定に調整を加える必要がある場合は、[編集] を選択できます。

発行ブランチを更新したり、ADF スタジオの発行ボタンを無効にするかどうかを決定したりできます。 スタジオの発行ボタンを無効にすることを選択すると、スタジオ内の発行ボタンが淡色表示になります。 これは、最後に自動発行されたデプロイが上書きされるのを回避するのに役立ちます。

GitHub 組織

GitHub 組織に接続するには、Azure Data Factory のアクセス許可を組織に付与する必要があります。 組織に対する管理者アクセス許可を持つユーザーは、以下の手順を実行して、データ ファクトリに接続できるようにする必要があります。

Azure Data Factory で初めてパブリック GitHub または GitHub Enterprise Cloud に接続する

初めて Azure Data Factory からパブリック GitHub または GitHub Enterprise Cloud に接続している場合は、次の手順のようにして GitHub 組織に接続します。

1. [Git 構成] ウィンドウの [GitHub アカウント] フィールドに組織名を入力します。 GitHub にログインするためのプロンプトが表示されます。
2. ユーザー資格情報を使用してサインインします。
3. Azure Data Factory を AzureDataFactory と呼ばれるアプリケーションとして認可するように求められます。 この画面には、ADF が組織にアクセスするためにアクセス許可を付与するためのオプションが表示されます。 アクセス許可を付与するオプションが表示されない場合は、GitHub でアクセス許可を手動で付与するように管理者に依頼してください。

これらの手順に従うと、ファクトリは組織内のパブリックとプライベートの両方のリポジトリに接続できるようになります。 接続できない場合は、ブラウザーのキャッシュをクリアして再試行してください。

個人用アカウントを使用してパブリック GitHub または GitHub Enterprise Cloud に既に接続している

既にパブリック GitHub または GitHub Enterprise Cloud に接続していて、個人アカウントへのアクセス許可のみが付与されている場合は、次の手順のようにして、組織へのアクセス許可を付与します。

1. GitHub に移動して [設定] を開きます。

   

2. [アプリケーション] を選択します。 [Authorized OAuth Apps](認可済み OAuth アプリ) タブに AzureDataFactory が表示されます。

   

3. アプリケーションを選択し、アプリケーションに組織へのアクセス権を付与します。

   

これらの手順に従うと、ファクトリは組織内のパブリックとプライベートの両方のリポジトリに接続できるようになります。

GitHub Enterprise Server に接続する

GitHub Enterprise Server に接続する場合は、認証に個人用アクセス トークンを使う必要があります。 個人用アクセス トークンを作成する方法については、「個人用アクセス トークンを作成する」をご覧ください。

GitHub の既知の制限事項

• スクリプトとデータ ファイルは GitHub リポジトリに格納できます。 ただし、Azure Storage に手動でファイルをアップロードする必要があります。 Data Factory パイプラインでは、GitHub リポジトリに保存されているスクリプトまたはデータ ファイルが Azure Storage に自動的にアップロードされません。

• GitHub Enterprise 2.14.0 より前のバージョンは Microsoft Edge ブラウザーで動作しません。

• Data Factory ビジュアル作成ツールと GitHub の統合は、一般的に利用できるバージョンの Data Factory でのみ機能します。

Azure DevOps Server 2022 への接続

Azure DevOps Server 2022 に接続するには、認証に個人用アクセス トークンを使用する必要があります。 個人用アクセス トークンを作成する方法については、こちらを参照してください。

Azure DevOps Server URL と Azure DevOps Project Collection を指定して、オンプレミスの Azure DevOps に接続します

コードの読み取り/書き込みとしてアクセス スコープを持つトークンを指定します。

バージョン コントロール

開発者は、バージョン コントロール (ソース管理 とも呼ばれます) システムを使うことで、コードの共同作業を行い、コード ベースに対して行われた変更を追跡することができます。 ソース管理は、複数の開発者で行うプロジェクトに不可欠なツールです。

機能ブランチの作成

データ ファクトリに関連付けられている各 Azure Repos Git リポジトリには、コラボレーション ブランチが存在します。 (main は既定のコラボレーション ブランチです)。 ユーザーは、ブランチのドロップダウンで [+ New Branch](新しいブランチ) をクリックして機能分岐を作成することもできます。

新しいブランチ ペインが表示されたら、機能ブランチの名前を入力し、作業の基にするブランチを選択します。

機能ブランチの変更をコラボレーション ブランチにマージする準備ができたら、ブランチのドロップダウンをクリックし、 [Create pull request](pull request の作成) を選択します。 このアクションで Azure Repos Git に移動します。Azure Repos Git では、pull request の発行、コード レビューの実行、およびコラボレーション ブランチへの変更のマージを行うことができます。 (main が既定値です)。 コラボレーション ブランチからは、Data Factory サービスにのみ発行することができます。

発行の設定を構成する

既定のデータ ファクトリでは、公開されたファクトリの Resource Manager テンプレートが生成され、adf_publish という名前のブランチにそれが保存されます。 カスタムの公開ブランチを構成するには、コラボレーション ブランチのルート フォルダーに publish_config.json ファイルを追加します。 公開時、ADF ではこのファイルを読み込み、フィールド publishBranch を探し、Resource Manager テンプレートをすべて、指定の場所に保存します。 ブランチが存在しない場合は、データ ファクトリによって自動的に作成されます。 このファイルは、次のようになります。

{
    "publishBranch": "factory/adf_publish"
}

Azure Data Factory に指定できる公開ブランチは一度に 1 つとなっています。 新しい発行ブランチが指定されたとき､Data Factory は前回の発行ブランチを削除しません｡ 以前の発行ブランチを削除する場合は、それを手動で削除します。

コード変更の発行

コラボレーション ブランチ (main が既定値) に変更をマージしたら、 [発行] をクリックして、メイン ブランチ内のコード変更を Data Factory サービスに手動で発行します。

サイド ウィンドウが開き、発行ブランチと保留中の変更が正しいことを確認できます。 変更を確認したら、 [OK] をクリックして発行を確定します。

Git 統合のベスト プラクティス

アクセス許可

通常は、Data Factory を更新するアクセス許可をすべてのチーム メンバーには付与する必要はありません。 次のアクセス許可の設定をお勧めします。

• Data Factory に対する読み取りアクセス許可は、チーム メンバー全員に必要です。
• Data Factory への発行は、一部の選ばれたメンバーにのみ許可するようにします。 そのためには、Data Factory があるリソース グループで、Data Factory 共同作成者ロールを持つ必要があります。 アクセス許可の詳細については、「Azure Data Factory のロールとアクセス許可」を参照してください。

コラボレーション ブランチへの直接チェックインは許可しないことをお勧めします。 この制限は、すべてのチェックインが「機能ブランチの作成」に記載されている pull request のレビュー プロセスを通過するため、バグを防ぐのに役立ちます。

Azure Key Vault からのパスワードの使用

Data Factory のリンクされたサービスのすべての接続文字列またはパスワードまたはマネージド ID の認証を格納するために Azure Key Vault を使用することをお勧めします。 セキュリティ上の理由から、データ ファクトリでは、シークレットが Git に格納されません。 パスワードなどのシークレットを含むリンクされたサービスが変更されると、直後に、Azure Data Factory サービスに変更内容が発行されます。

また、Key Vault または MSI 認証を使用すると、Resource Manager テンプレートのデプロイ時にこれらのシークレットを指定する必要がなくなるため、継続的インテグレーションとデプロイが容易になります。

Git 統合のトラブルシューティング

古い発行ブランチ

以下に、古い発行ブランチが発生する可能性がある状況の例をいくつか示します。

• ユーザーに複数のブランチがある。 ユーザーが 1 つの機能ブランチで、AKV 関連ではないリンクされたサービスを削除し (非 AKV のリンクされたサービスは、Git にあるかどうかに関係なく、直ちに発行されます)、機能ブランチをコラボレーション ブランチにマージしませんでした。
• ユーザーが SDK または PowerShell を使用してデータ ファクトリを変更した
• ユーザーがすべてのリソースを新しいブランチに移動し、初めて発行を試みた。 リンクされたサービスは、リソースをインポートするときに手動で作成する必要があります。
• ユーザーが、非 AKV のリンクされたサービスまたは Integration Runtime JSON を手動でアップロードする。 それらは、データセット、リンクされたサービス、パイプラインなどの別のリソースからそのリソースを参照します。 ユーザー インターフェイスを使用して作成された非 AKV のリンクされたサービスは、資格情報を暗号化する必要があるため、直ちに発行されます。 そのリンクされたサービスを参照しているデータセットをアップロードして発行しようとすると、git 環境に存在するためにユーザー インターフェイスはそれを許可します。 これは、データ ファクトリ サービスに存在しないため、発行時に拒否されます。

発行ブランチがメイン ブランチと同期しておらず、最新の発行があっても古いリソースが含まれている場合は、次のいずれかの解決策を使用できます。

オプション 1: ライブ モードの上書き機能を使用する

コラボレーション ブランチのコードがライブ モードに発行または上書きされます。 リポジトリ内のコードが信頼できる情報源と見なされます。

コード フロー: コラボレーション ブランチ -> ライブ モード

オプション 2: Git リポジトリを切断して再接続する

コードがライブ モードからコラボレーション ブランチにインポートされます。 ライブ モードのコードが信頼できる情報源と見なされます。

コード フロー: ライブ モード -> コラボレーション ブランチ

1. 現在の Git リポジトリを削除します
2. 同じ設定で Git を再構成しますが、[Import existing Data Factory resources to repository](既存の Data Factory リソースをリポジトリにインポートする) がオンになっていることを確認し、[Collaboration branch (same branch)](コラボレーション ブランチ (同じブランチ)) を選択します
3. 変更をコラボレーション ブランチにマージするプル要求を作成します。

必要に応じて、いずれかの方法を選択します。

発行時にすべてのリソースが新規と表示される

公開中、以前に公開されたリソースであっても、すべてのリソースが新規として表示されることがあります。 これは、ファクトリの ARM テンプレートを再デプロイするか、PowerShell または REST API を使用してファクトリの repoConfiguration プロパティを更新することにより、ファクトリの repoConfiguration プロパティで lastCommitId プロパティがリセットされた場合に発生します。 リソース発行を続けると問題は解決しますが、再発防止のため、ファクトリの repoConfiguration プロパティを更新することは避けてください。

別の Git リポジトリに切り替える

別の Git リポジトリに切り替えるには、 [ソース管理] の管理ハブにある [Git 構成] ページに移動します。 [切断] を選択します。

データ ファクトリ名を入力し、 [confirm](確認) をクリックして、データ ファクトリに関連付けられている Git リポジトリを削除します。

現在のリポジトリとの関連付けを削除すると、別のリポジトリを使用するように Git 設定を構成してから、既存の Data Factory リソースを新しいリポジトリにインポートできるようになります。

関連するコンテンツ

• パイプラインの監視と管理について詳しくは、プログラムでのパイプラインの監視と管理に関する記事をご覧ください。
• 継続的インテグレーションとデプロイを実装するには、「Azure Data Factory における継続的インテグレーションと継続的デリバリー (CI/CD)」を参照してください。