Azure Data Factory ソリューションのソース管理を管理する

  • 8 分

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

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

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

Note

Git リポジトリが構成されている場合、Azure Data Factory UX では Data Factory サービスを使用した直接作成は無効になります。 PowerShell または SDK を使用して行われた変更は、Data Factory サービスに直接発行され、Git には入力されません。

Git 統合の利点

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

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

Git リポジトリに接続する

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

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

Azure Data Factory のホームページで、 [Set up Code Repository](コード リポジトリの設定) を選択します。

Configure a code repository from home page

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

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

Configure the code repository settings from authoring

構成方法 3:管理ハブ

Azure Data Factory UX で管理ハブに移動します。 [ソース管理] セクションで [Git 構成] を選択します。 接続されているリポジトリがない場合は、 [Set up Code Repository](コード リポジトリの設定) をクリックします。

Configure the code repository settings from management hub

バージョン コントロール

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

機能ブランチの作成

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

Create a new branch

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

Create a new pull request

発行の設定を構成する

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

{
    "publishBranch": "factory/adf_publish"
}

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

Note

Data Factory はファクトリを読み取るときに publish_config.json ファイルを読み取るだけです｡ ポータルにファクトリをすでに読み込んでいる場合は､ブラウザを最新の情報に更新することで､変更が有効になっていることを確認することができます｡

コード変更の発行

コラボレーション ブランチに変更をマージした後、[発行] をクリックして、コラボレーション ブランチ内のコード変更を Data Factory サービスに手動で発行します。

Publish changes to the Data Factory service

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

Confirm the correct publish branch

重要

コラボレーション ブランチは、Data Factory サービスにデプロイされるものを表しているわけではありません。 コラボレーション ブランチは Data Factory サービスに手動で発行する "必要があります"。

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

アクセス許可

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

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

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

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

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

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

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

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

Git icon

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

Remove the association with the current Git repo

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

重要

データ ファクトリから Git 構成を削除しても、リポジトリからは何も削除されません。 ファクトリには、公開されたすべてのリソースが含まれます。 引き続きサービスに対して直接、ファクトリを編集できます。