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 統合された平均的なファクトリは、データ ファクトリ サービスを直接利用する場合に比べ、読み込み速度が10倍速くなります。 このパフォーマンスの向上は、リソースが Git 経由でダウンロードされることに起因します。

Git リポジトリに接続する

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

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

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

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

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

構成方法 3:管理ハブ

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

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

Azure ポータルで新しいデータ ファクトリを作成する場合は、Git 構成 タブで Git リポジトリ情報を構成できます。

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

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

Azure Repos設定

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

リポジトリ設定の編集

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

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

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

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

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

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

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

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

3. Azure DevOps セクションに移動すると、個人用リポジトリが表示されます。 リポジトリを選択し、Active Directoryに接続します。

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

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

GitHub統合を持って執筆する

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

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

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

GitHub設定

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

リポジトリ設定の編集

構成したGitHub リポジトリの設定を調整する必要がある場合は、Edit を選択できます。

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

GitHub組織

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

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

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

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

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

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

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

1. GitHubに移動し、Settings を開きます。

   

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

   

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

   

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

GitHub Enterprise Server への接続

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

既知のGitHubの制限事項

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

• 2.14.0 より前のバージョンの GitHub Enterprise は、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 に移動し、プル要求を発行したり、コードレビューを行ったり、コラボレーションブランチに変更をマージしたりすることができます。 (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からのパスワードの使用

Azure Key Vaultを使用して、Data Factory のリンクされたサービスの接続文字列またはパスワードまたはマネージド ID 認証を格納することをお勧めします。 セキュリティ上の理由から、データ ファクトリでは、シークレットが 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を参照してください。