Azure Data Factory における継続的インテグレーションとデリバリー
適用対象: 
Azure Data Factory 
Azure Synapse Analytics
ヒント
企業向けのオールインワン分析ソリューション、Microsoft Fabric の Data Factory をお試しください。 Microsoft Fabric は、データ移動からデータ サイエンス、リアルタイム分析、ビジネス インテリジェンス、レポートまで、あらゆるものをカバーしています。 無料で新しい試用版を開始する方法について説明します。
継続的インテグレーションは、コードベースに対して行われた変更を、できるだけ早く自動的にテストするプラクティスです。 継続的デリバリーは、継続的インテグレーションの間に発生したテストに続けて、変更をステージングまたは実稼働システムにプッシュします。
Azure Data Factory では、継続的インテグレーションと継続的デリバリー (CI/CD) とは、Data Factory パイプラインをある環境 (開発、テスト、運用) から別の環境に移動することを意味します。 Azure Data Factory では Azure Resource Manager テンプレートを活用し、さまざまな ADF エンティティ (パイプライン、データセット、データ フローなど) の構成を保存します。 データ ファクトリを別の環境に昇格させる手法が 2 つ提案されています。
- Data Factory と Azure Pipelines の統合を利用した自動化されたデプロイ
- Data Factory UX と Azure Resource Manager の統合を利用した Resource Manager テンプレートの手動アップロード。
注意
Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。 作業を始めるには、「Azure PowerShell をインストールする」を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。
CI/CD のライフサイクル
Note
詳細については、「継続的なデプロイの機能強化」を参照してください。
Azure Repos Git で構成された Azure Data Factory での CI/CD のライフサイクルのサンプル概要を以下に示します。 Git リポジトリを構成する方法の詳細については、「Azure Data Factory のソース管理」を参照してください。
Azure Repos Git で開発データ ファクトリが作成され、構成されます。 すべての開発者には、パイプラインやデータセットなどの Data Factory リソースを作成するためのアクセス許可が必要です。
開発者は変更を行う目的で機能ブランチを作成します。 一番新しい変更を利用し、パイプライン実行をデバッグします。 パイプライン実行をデバッグする方法の詳細については、「Azure Data Factory での反復開発とデバッグ」を参照してください。
開発者は、変更の結果に問題がなければ、各自の機能ブランチからメインまたはコラボレーション ブランチへのプル要求を作成して、同僚が変更をレビューできるようにします。
プル要求が承認され、変更がメイン ブランチにマージされたら、変更が開発ファクトリに発行されます。
チームは、変更をテストまたは UAT (ユーザー受け入れテスト) ファクトリにデプロイする準備ができたら、Azure Pipelines リリースに進み、望ましいバージョンの開発ファクトリを UAT にデプロイします。 このデプロイは Azure Pipelines タスクの一環として行われ、Resource Manager テンプレート パラメーターを使用し、適切な構成を適用します。
テスト ファクトリで変更の妥当性が確認されたら、パイプライン リリースの次のタスクを利用し、運用環境のファクトリにデプロイします。
Note
開発ファクトリのみ、Git リポジトリに関連付けられます。 テスト ファクトリと運用環境のファクトリには Git リポジトリを関連付けません。更新には必ず Azure DevOps パイプラインか Resource Management テンプレートを利用してください。
下の図は、このライフサイクルのさまざまなステップを示しています。
CI/CD のベスト プラクティス
データ ファクトリとの Git 統合を使用していて、変更を開発からテストを経て運用環境に移行する CI/CD パイプラインがある場合は、次のベスト プラクティスをお勧めします。
Git 統合。 Git 統合で開発データ ファクトリのみを構成します。 テスト環境と運用環境への変更は CI/CD を介してデプロイされるので、Git 統合は必要ありません。
デプロイ前とデプロイ後のスクリプト。 CI/CD の Resource Manager のデプロイ手順の前に、トリガーの停止と再起動やクリーンアップの実行など、特定のタスクを完了する必要があります。 デプロイ タスクの前後に PowerShell スクリプトを使用することをお勧めします。 詳細については、「アクティブなトリガーを更新する」を参照してください。 データ ファクトリ チームは、このページの終わりに使用するスクリプトを提供しています。
Note
CI/CD 中にすべてのトリガーをオフ/オンにするのではなく、変更されたトリガーのみをオフ/オンにする場合は、PrePostDeploymentScript.Ver2.ps1 を使用します。
警告
ADO タスクで PowerShell Core を使用してスクリプトを実行してください。
警告
最新バージョンの PowerShell および Data Factory モジュールを使用しない場合は、コマンドの実行中に逆シリアル化エラーが発生する可能性があります。
統合ランタイムと共有。 統合ランタイムは頻繁には変更されず、CI/CD のすべてのステージで類似しています。 そのため、Data Factory では、CI/CD のすべてのステージで統合ランタイムの名前、種類、サブタイプを同じにすることが求められます。 すべてのステージで統合ランタイムを共有する場合は、共有の統合ランタイムを含めるためだけに三項ファクトリを使用することを検討してください。 この共有ファクトリは、すべての環境で、リンクされた統合ランタイムの種類として使用できます。
Note
統合ランタイムの共有は、セルフホステッド統合ランタイムでのみ利用できます。 Azure-SSIS 統合ランタイムの共有はサポートされせん。
マネージド プライベート エンドポイント デプロイ。 プライベート エンドポイントがファクトリに既に存在している場合、同じ名前と変更されたプロパティを持つプライベート エンドポイントを含む ARM テンプレートをデプロイしようとすると、デプロイが失敗します。 つまり、既にファクトリに存在するものと同じプロパティを持つ限り、プライベート エンド ポイントを正常にデプロイできます。 環境によってプロパティが異なる場合は、そのプロパティをパラメーター化し、デプロイ時にそれぞれの値を指定することでオーバーライドできます。
Key Vault。 リンクされているサービスを使用するとき、その接続情報が Azure Key Vault に格納されている場合、キー コンテナーを環境別に保持することが推奨されます。 キー コンテナーごとに個別のアクセス許可レベルを構成することもできます。 たとえば、運用環境のシークレットへのアクセス許可をチーム メンバーに持たせたくない場合があります。 このアプローチに従う場合は、すべてのステージで同じシークレット名を保持することをお勧めします。 同じシークレット名を保持する場合、CI/CD 環境全体で各接続文字列をパラメーター化する必要はありません。変わるのは別個のパラメーターであるキー コンテナーの名前だけだからです。
リソースの名前付け。 ARM テンプレートの制約により、リソースの名前にスペースが含まれていると、デプロイで問題が発生する可能性があります。 Azure Data Factory チームは、リソースではスペースの代わりに "_" または "-" 文字を使用することをお勧めします。 たとえば、"Pipeline 1" ではなく "Pipeline_1" という名前を使用します。
リポジトリの変更。 ADF では GIT リポジトリのコンテンツが自動的に管理されます。 関連のないファイルまたはフォルダーを ADF Git リポジトリ データ フォルダー内の任意の場所に手動で変更または追加すると、リソースの読み込みエラーが発生する可能性があります。 たとえば、.bak ファイルが存在すると ADF CI/CD エラーが発生する可能性があるため、ADF を読み込むには削除する必要があります。
露出調整と機能フラグ。 チームで作業しているときに、変更をマージしても、PROD や QA などより高度な環境では実行したくない場合があるとします。 このようなシナリオに対応するため、ADF チームでは、機能フラグを使用する DevOps 構想をお勧めしています。 ADF では、グローバル パラメーターと If Condition アクティビティを組み合わせて、これらの環境フラグに基づいてロジックのセットを非表示にすることができます。
機能フラグを設定する方法については、次のビデオ チュートリアルをご覧ください。
サポートされていない機能
設計上、Data Factory では、コミットのチェリーピックやリソースの選択的発行は許可されません。 発行には、データ ファクトリで加えられたすべての変更が含まれます
- データ ファクトリのエンティティは相互に依存しています。 たとえば、トリガーはパイプラインに依存し、パイプラインはデータセットや他のパイプラインに依存しています。 リソースのサブセットを選択的に発行すると、予期しない動作やエラーにつながる可能性があります。
- まれに、選択的な発行が必要になった場合は、修正プログラムの使用を検討してください。 詳細については、「運用環境への修正プログラムの適用」を参照してください。
Azure Data Factory チームでは、データ ファクトリ内の個々のエンティティ (パイプライン、データセットなど) に Azure RBAC 制御を割り当てることを推奨していません。 たとえば、開発者がパイプラインまたはデータセットにアクセスできる場合、データ ファクトリ内のすべてのパイプラインまたはデータセットにアクセスできるはずです。 データ ファクトリ内に多数の Azure RBAC ロールを実装する必要があると思う場合は、2 つ目のデータ ファクトリをデプロイすることを検討してください。
非公開のブランチから発行することはできません。
現在、Bitbucket でプロジェクトをホストすることはできません。
現在、アラートとマトリックスをパラメーターとしてエクスポートおよびインポートすることはできません。
発行ブランチの部分的な ARM テンプレートは、2021 年 11 月 1 日以降サポートされなくなりました。 プロジェクトでこの機能を利用していた場合は、
ARMTemplateForFactory.jsonまたはlinkedTemplatesファイルを使用する、サポートされているデプロイ メカニズムに切り替えてください。