Azure Data Factory のソース管理
適用対象:
Azure Data Factory 
Azure Synapse Analytics
ヒント
企業向けのオールインワン分析ソリューション、Microsoft Fabric の Data Factory をお試しください。 Microsoft Fabric は、データ移動からデータ サイエンス、リアルタイム分析、ビジネス インテリジェンス、レポートまで、あらゆるものをカバーしています。 無料で新しい試用版を開始する方法について説明します。
既定の 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 パターンの詳細を確認することもできます。
Note
21Vianet によって運営される Azure Gov と Microsoft Azure に GitHub パブリック サポートを追加しました。 お知らせブログを参照してください。
Azure Data Factory を Git と統合する方法の詳細については、次の 15 分のチュートリアル ビデオをご覧ください。
Git 統合の利点
Git 統合が作成作業にもたらす利点をいくつか下の一覧にまとめています。
- ソース管理: データ ファクトリのワークロードの重要性が高まると、ソース管理に関して以下に示すような利点を活用するために、そのファクトリと Git を統合する必要性を感じることも出てきます。
- 変更の追跡と監査の機能
- バグの原因となっている変更を元に戻す機能
- 途中保存: データ ファクトリ サービスに対して作成するとき、変更内容を下書きとして保存することはできません。公開内容はすべて、データ ファクトリの妥当性確認に合格する必要があります。 パイプラインが完了していない場合、あるいは単純に、コンピューターがクラッシュして変更内容が失われては困るときに、Git 統合によって、データ ファクトリ リソースの状態に関係なく、データ ファクトリ リソースを増分方式で変更することができます。 Git リポジトリを構成すると、変更内容を保存できます。変更内容に満足できるまでテストしてから公開できます。
- コラボレーションと管理: 同じファクトリに複数のチーム メンバーが貢献している場合、コード レビューのプロセスを通じてチームメイトが相互に共同作業できるようにすることが必要な場合があります。 共同作成者ごとにアクセス許可を変えるようにファクトリを設定することもできます。 一部のチーム メンバーに Git 経由での変更のみを許可し、チーム内の特定のメンバーにファクトリの変更の公開を許可するとします。
- CI/CD の改善:継続的デリバリー プロセスで複数の環境にデプロイしている場合、Git 統合で特定のアクションが簡単になります。 そうしたアクションの例を次に示します。
- "開発" ファクトリに何か変更があった時点ですぐに自動でトリガーされるようにリリース パイプラインを構成します。
- Resource Manager テンプレートのパラメーターとして利用可能なプロパティをファクトリ内でカスタマイズします。 これは、必要なプロパティのみをパラメーターにして、残りをすべてハード コーディングする場合に便利です。
- パフォーマンスの向上: Git 統合の平均的なファクトリでは、データ ファクトリ サービスに対し、作成が 1 つの場合に比べ、読み込み速度が 10 倍になります。 このパフォーマンスの向上は、リソースが Git 経由でダウンロードされることに起因します。
Note
Git リポジトリが構成されている場合、Azure Data Factory UX では Data Factory サービスを使用した直接作成は無効になります。 PowerShell または SDK を使用して行われた変更は、Data Factory サービスに直接発行され、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 リポジトリの情報を構成できます。
Note
Azure portal で git を構成する場合は、プロジェクト名やリポジトリ名などの設定を、ドロップダウンの一部としてではなく、手動で入力する必要があります。
Azure Repos Git 統合を使用した作成
Azure Repos Git 統合を使ったビジュアルの作成では、データ ファクトリ パイプラインでの作業時にソース管理とコラボレーションがサポートされます。 ソース管理やコラボレーション、バージョン管理などで､データ ファクトリを Azure Repos Git 統合リポジトリに関連付けることができます。 各 Azure Repos Git 組織は複数のレポジトリを持つことができますが､1つの Azure Repos Git リポジトリに関連付けられるデータ ファクトリの数は 1 つだけです｡ Azure Repos アカウントまたはリポジトリがない場合は、こちらの手順に従ってリソースを作成します。
Note
スクリプトとデータ ファイルは Azure Repos Git リポジトリに格納できます。 ただし、Azure Storage に手動でファイルをアップロードする必要があります。 データ ファクトリ パイプラインは、Azure Repos Git リポジトリに保存されているスクリプトまたはデータ ファイルを Azure Storage に自動的にアップロードしません。 ARM テンプレート、スクリプト、構成ファイルなどの追加ファイルは、マップされたフォルダーの外部のリポジトリに格納できます。 これを行う場合は、マップされた Azure DevOps フォルダーの外部に格納されているファイルをビルド/デプロイおよび操作するために、追加のタスクが必要であることに注意してください。
Azure Repos の設定
![[リポジトリの構成] 設定を示すスクリーンショット。](media/author-visually/repo-settings.png)
構成ペインでは、次のコード リポジトリの各設定を構成する手順について説明します。
| 設定 | 説明 | 値 |
|---|---|---|
| リポジトリの種類 | Azure Repos コード リポジトリの種類。 |
Azure DevOps Git または GitHub |
| Microsoft Entra ID | Microsoft Entra テナント名。 | <your tenant name> |
| Azure Repos Organization | Azure Repos 組織の名前｡ Azure Repos 組織名はhttps://{organization name}.visualstudio.comで確認することができます｡ Azure Repos 組織にサインインし、お使いの Visual Studio プロファイルにアクセスして、リポジトリとプロジェクトを確認してください。 |
<your organization name> |
| ProjectName | Azure Repos プロジェクトの名前。 Azure Repos プロジェクトの名前は https://{organization name}.visualstudio.com/{project name} で確認することができます｡ |
<your Azure Repos project name> |
| RepositoryName | Azure Repos コード リポジトリの名前｡ Azure Repos プロジェクトには、プロジェクトの拡大に合わせてソース コードを管理するための Git リポジトリが含まれます。 新しいリポジトリを作成するか、プロジェクト内に既にある既存のリポジトリを使用できます。 | <your Azure Repos code repository name> |
| コラボレーション ブランチ | 発行に使用する Azure Repos コラボレーション ブランチ。 既定では、これは main です。 別のブランチからのリソースを発行する場合は、この設定を変更します。 |
<your collaboration branch name> |
| 発行ブランチ | 発行ブランチは、リポジトリ内の、発行に関する ARM テンプレートが保存および更新されるブランチです。 既定では、これは adf_publish です。 |
<your publish branch name> |
| ルート フォルダー | Azure Repos コラボレーション ブランチのルート フォルダー。 | <your root folder name> |
| [Import existing Data Factory resources to repository](既存の Data Factory リソースをリポジトリにインポートする) | UX 作成キャンバスからの既存のデータ ファクトリ リソースを Azure Repos Git リボジトリにインポートするかどうかを指定します。 オンにすると、JSON 形式でデータ ファクトリ リソースを関連付けられている Git リポジトリにインポートします。 このアクションでは、各リソースが個別にエクスポートされます (つまり、リンクされたサービスとデータセットは、異なる JSON にエクスポートされます)。 このボックスを選択しなかった場合、既存のリソースはインポートされません。 | 選択済み (既定値) |
| Branch to import resource into | データ ファクトリのリソース (パイプライン、データセット、リンクされたサービスなど) をインポートするブランチを指定します。 次のブランチのいずれかにリソースをインポートできます。a. コラボレーション b. 新規作成 c. 既存のものを使用 |
Note
Microsoft Edge を使用していて、Azure DevOps アカウントのドロップダウンに値が表示されない場合は、 https://*.visualstudio.com を信頼済みサイト一覧に追加します。
リポジトリ設定の編集
構成した Azure Repos Git リポジトリの設定に調整を加える必要がある場合は、[編集] を選択できます。
発行ブランチを更新したり、ADF スタジオの発行ボタンを無効にするかどうかを決定したりできます。 スタジオの発行ボタンを無効にすることを選択すると、スタジオ内の発行ボタンが淡色表示になります。 こうすると、最後に自動発行されたデプロイが上書きされるのを回避する助けになります。
別の Microsoft Entra テナントを使用する
Azure Repos Git リポジトリは、別の Microsoft Entra テナントに配置できます。 別の Microsoft Entra テナントを指定するには、使用している Azure サブスクリプションの管理者のアクセス許可が必要です。 詳細については、サブスクリプション管理者の変更に関する記事を参照してください。
重要
別の Microsoft Entra ID に接続するには、ログインしたユーザーがその Active Directory の一部である必要があります。
個人用の Microsoft アカウントを使用する
Git の統合に個人用の Microsoft アカウントを使用するには、Azure の個人用のリポジトリを組織の Active Directory にリンクできます。
個人用の Microsoft アカウントを組織の Active Directory にゲストとして追加します。 詳細については、Azure portal での Microsoft Entra B2B コラボレーション ユーザーの追加に関するページを参照してください。
個人用の Microsoft アカウントを使用して、Azure portal にサインインします。 その後組織の Active Directory に切り替えます。
Azure DevOps セクションに移動すると、個人用のリポジトリがあることを確認できます。 リポジトリを選択し、Active Directory に接続します。
これらの構成手順を実行すると、Data Factory UI で Git 統合を設定するときに個人用のリポジトリを使用できます。
Azure Repos を組織の Active Directory に接続する方法の詳細については、Microsoft Entra ID に Azure DevOps 組織を接続する方法に関するページを参照してください。
GitHub 統合での作成
GitHub 統合を使用したビジュアルの作成では、データ ファクトリ パイプラインの使用にあたりソース管理とコラボレーションがサポートされています。 データ ファクトリを GitHub account リポジトリと関連付けて、ソース管理、コラボレーション、バージョン管理などを行うことができます。 1 つの GitHub アカウントで複数のリポジトリを使用できますが、1 つの GitHub リポジトリに関連付けられるのは 1 つのデータ ファクトリのみです。 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 アプリからリポジトリへのアクセスが可能になるのみです。
Note
Microsoft Edge を使用している場合、2.1.4 より前の GitHub Enterprise バージョンでは機能しません。 GitHub で公式にサポートされているのは 3.0 以上であり、これらはすべて ADF に対して問題がありません。 GitHub で最小バージョンが変更されると、ADF でサポートされるバージョンも変更されます。
GitHub の設定
![GitHub の [Configure a repository] (リポジトリの構成) ペインを示すスクリーンショット。](media/author-visually/github-configure-repository-pane.png)
[構成] ウィンドウには、次の GitHub リポジトリの設定が表示されます。
| 設定 | 説明 | Value |
|---|---|---|
| リポジトリの種類 | Azure Repos コード リポジトリの種類。 | GitHub |
| Use GitHub Enterprise Server (GitHub Enterprise Server を使用する) | GitHub Enterprise Server を選ぶチェックボックス。 | オフ (既定値) |
| GitHub Enterprise Server URL (GitHub Enterprise Server の URL) | GitHub Enterprise ルート URL (ローカル GitHub Enterprise サーバーの場合は HTTPS である必要があります)。 (例: https://github.mydomain.com)。 [Use GitHub Enterprise Server] (GitHub Enterprise Server を使用する) がオンの場合にのみ必要です |
<your GitHub Enterprise Server URL> |
| GitHub repository owner (GitHub リポジトリの所有者) | リポジトリを所有する GitHub 組織またはアカウント。 この名前は、https://github.com/{owner}/{repository name} で確認できます。 このページに移動すると、GitHub の組織またはアカウントの GitHub OAuth 資格情報を入力するよう求められます。 [GitHub Enterprise Server を使用する] を選んだ場合は、ダイアログ ボックスが表示され、アクセス トークンを入力できます。 | <your GitHub repository owner name> |
| リポジトリ名 | GitHub コード リポジトリ名。 GitHub アカウントには、ソース コードを管理するための Git リポジトリが含まれます。 新しいリポジトリを作成するか、プロジェクト内の既存のリポジトリを使用できます。 [Select repository] (リポジトリを選択する) を選んだときは、GitHub コード リポジトリの名前を指定します。 | <your repository name> |
| Git repository link (Git リポジトリのリンク) | GitHub コード リポジトリのリンク。 [Use repository link] (リポジトリのリンクを使用する) を選んだときは、GitHub コード リポジトリのリンクを指定します。 | <your repository link> |
| コラボレーション ブランチ | 発行に使用される GitHub コラボレーション ブランチ。 既定ではメインです。 別のブランチからのリソースを発行する場合は、この設定を変更します。 ここで新しいコラボレーション ブランチを作成することもできます。 | <your collaboration branch> |
| 発行ブランチ | 発行に関する ARM テンプレートが格納および更新される、リポジトリ内のブランチ。 | <your publish branch name> |
| ルート フォルダー | GitHub コラボレーション ブランチのルート フォルダー。 | <your root folder name> |
| [Import existing resources to repository](既存のリソースをリポジトリにインポートする) | UX 作成キャンバスからの既存のデータ ファクトリ リソースを GitHub リボジトリにインポートするかどうかを指定します。 オンにすると、JSON 形式でデータ ファクトリ リソースを関連付けられている Git リポジトリにインポートします。 このアクションでは、各リソースが個別にエクスポートされます (つまり、リンクされたサービスとデータセットは、異なる JSON にエクスポートされます)。 このボックスを選択しなかった場合、既存のリソースはインポートされません。 | 選択済み (既定値) |
| [Import resource into this branch](リソースをこのブランチにインポートする) | データ ファクトリのリソース (パイプライン、データセット、リンクされたサービスなど) をインポートするブランチを指定します。 |
リポジトリ設定の編集
構成した GitHub リポジトリの設定に調整を加える必要がある場合は、[編集] を選択できます。
発行ブランチを更新したり、ADF スタジオの発行ボタンを無効にするかどうかを決定したりできます。 スタジオの発行ボタンを無効にすることを選択すると、スタジオ内の発行ボタンが淡色表示になります。 これは、最後に自動発行されたデプロイが上書きされるのを回避するのに役立ちます。
GitHub 組織
GitHub 組織に接続するには、Azure Data Factory のアクセス許可を組織に付与する必要があります。 組織に対する管理者アクセス許可を持つユーザーは、以下の手順を実行して、データ ファクトリに接続できるようにする必要があります。
Azure Data Factory で初めてパブリック GitHub または GitHub Enterprise Cloud に接続する
初めて Azure Data Factory からパブリック GitHub または GitHub Enterprise Cloud に接続している場合は、次の手順のようにして GitHub 組織に接続します。
- [Git 構成] ウィンドウの [GitHub アカウント] フィールドに組織名を入力します。 GitHub にログインするためのプロンプトが表示されます。
- ユーザー資格情報を使用してサインインします。
- Azure Data Factory を AzureDataFactory と呼ばれるアプリケーションとして認可するように求められます。 この画面には、ADF が組織にアクセスするためにアクセス許可を付与するためのオプションが表示されます。 アクセス許可を付与するオプションが表示されない場合は、GitHub でアクセス許可を手動で付与するように管理者に依頼してください。
これらの手順に従うと、ファクトリは組織内のパブリックとプライベートの両方のリポジトリに接続できるようになります。 接続できない場合は、ブラウザーのキャッシュをクリアして再試行してください。
個人用アカウントを使用してパブリック GitHub または GitHub Enterprise Cloud に既に接続している
既にパブリック GitHub または GitHub Enterprise Cloud に接続していて、個人アカウントへのアクセス許可のみが付与されている場合は、次の手順のようにして、組織へのアクセス許可を付与します。
GitHub に移動して [設定] を開きます。
[アプリケーション] を選択します。 [Authorized OAuth Apps](認可済み OAuth アプリ) タブに AzureDataFactory が表示されます。
アプリケーションを選択し、アプリケーションに組織へのアクセス権を付与します。
これらの手順に従うと、ファクトリは組織内のパブリックとプライベートの両方のリポジトリに接続できるようになります。
GitHub Enterprise Server に接続する
GitHub Enterprise Server に接続する場合は、認証に個人用アクセス トークンを使う必要があります。 個人用アクセス トークンを作成する方法については、「個人用アクセス トークンを作成する」をご覧ください。
Note
GitHub Enterprise Server はセルフホステッド プライベート環境内にあるため、この認証を使うときは、ファイアウォール、ネットワーク ポリシー、VPN に対するフル コントロールが必要です。 詳しくは、「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 は前回の発行ブランチを削除しません｡ 以前の発行ブランチを削除する場合は、それを手動で削除します。
Note
Data Factory はファクトリを読み取るときに publish_config.json ファイルを読み取るだけです｡ ポータルにファクトリをすでに読み込んでいる場合は､ブラウザを最新の情報に更新することで､変更が有効になっていることを確認することができます｡
コード変更の発行
コラボレーション ブランチ (main が既定値) に変更をマージしたら、 [発行] をクリックして、メイン ブランチ内のコード変更を Data Factory サービスに手動で発行します。
サイド ウィンドウが開き、発行ブランチと保留中の変更が正しいことを確認できます。 変更を確認したら、 [OK] をクリックして発行を確定します。
重要
メイン ブランチは Data Factory サービスに展開されているものを代表しているわけではありません。 メイン ブランチを Data Factory サービスに手動で発行する "必要があります"。
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 リポジトリを切断して再接続する
コードがライブ モードからコラボレーション ブランチにインポートされます。 ライブ モードのコードが信頼できる情報源と見なされます。
コード フロー: ライブ モード -> コラボレーション ブランチ
- 現在の Git リポジトリを削除します
- 同じ設定で Git を再構成しますが、[Import existing Data Factory resources to repository](既存の Data Factory リソースをリポジトリにインポートする) がオンになっていることを確認し、[Collaboration branch (same branch)](コラボレーション ブランチ (同じブランチ)) を選択します
- 変更をコラボレーション ブランチにマージするプル要求を作成します。
注意
直接コミットを許可しないリポジトリで作業している場合にのみ、pull request を作成してマージする必要があります。 ほとんどの組織では、リポジトリへの提出にはマージする前にレビューが必要になるため、通常はこのアプローチを使用することがベスト プラクティスです。 しかし、場合によってはレビューは必要ありません。その場合、pull request を作成してマージする必要はなく、変更はコラボレーション ブランチに直接コミットできます。
必要に応じて、いずれかの方法を選択します。
発行時にすべてのリソースが新規と表示される
公開中、以前に公開されたリソースであっても、すべてのリソースが新規として表示されることがあります。 これは、ファクトリの ARM テンプレートを再デプロイするか、PowerShell または REST API を使用してファクトリの repoConfiguration プロパティを更新することにより、ファクトリの repoConfiguration プロパティで lastCommitId プロパティがリセットされた場合に発生します。 リソース発行を続けると問題は解決しますが、再発防止のため、ファクトリの repoConfiguration プロパティを更新することは避けてください。
別の Git リポジトリに切り替える
別の Git リポジトリに切り替えるには、 [ソース管理] の管理ハブにある [Git 構成] ページに移動します。 [切断] を選択します。
データ ファクトリ名を入力し、 [confirm](確認) をクリックして、データ ファクトリに関連付けられている Git リポジトリを削除します。
現在のリポジトリとの関連付けを削除すると、別のリポジトリを使用するように Git 設定を構成してから、既存の Data Factory リソースを新しいリポジトリにインポートできるようになります。
重要
データ ファクトリから Git 構成を削除しても、リポジトリからは何も削除されません。 ファクトリには、発行されたすべてのリソースが含まれます。 引き続きサービスに対して直接、ファクトリを編集できます。
関連するコンテンツ
- パイプラインの監視と管理について詳しくは、プログラムでのパイプラインの監視と管理に関する記事をご覧ください。
- 継続的インテグレーションとデプロイを実装するには、「Azure Data Factory における継続的インテグレーションと継続的デリバリー (CI/CD)」を参照してください。