適用対象:
Azure Data Factory
Azure Synapse Analytics
ヒント
Data Factory in Microsoft Fabric は、よりシンプルなアーキテクチャ、組み込みの AI、および新機能を備えた次世代のAzure Data Factoryです。 データ統合を初めて使用する場合は、Fabric Data Factory から始めます。 既存の ADF ワークロードをFabricにアップグレードして、データ サイエンス、リアルタイム分析、レポートの新機能にアクセスできます。
継続的インテグレーションは、コードベースに対して行われた変更を、できるだけ早く自動的にテストするプラクティスです。 継続的デリバリーは、継続的インテグレーションの間に発生したテストに続けて、変更をステージングまたは実稼働システムにプッシュします。
Azure Data Factoryでは、継続的インテグレーションとデリバリー (CI/CD) とは、Data Factory パイプラインをある環境 (開発、テスト、運用) から別の環境に移動することを意味します。 Azure Data FactoryはAzure Resource Managerのテンプレートを使って、パイプライン、データセット、データフローなどのさまざまなData Factoryエンティティの設定を保存します。 データ ファクトリを別の環境に昇格させる手法が 2 つ提案されています。
- Data FactoryとAzure Pipelinesの統合による自動展開
- Data Factory UX と Azure Resource Manager の統合を使用して、Resource Manager テンプレートを手動でアップロードします。
Note
Azure Az PowerShell モジュールを使用してAzureを操作することをお勧めします。 作業を開始するには、「Install Azure PowerShellを参照してください。 Az PowerShell モジュールに移行する方法については、「
CI/CD のライフサイクル
Note
詳細については、「継続的なデプロイの機能強化」を参照してください。
以下の概要は、Azure Repos Gitで設定された Azure データファクトリーにおける CI/CD ライフサイクルを示しています。 Git リポジトリを構成する方法の詳細については、「Azure Data Factory の
開発データ ファクトリは、Azure Repos Git を使用して作成および構成されます。 すべての開発者には、パイプラインやデータセットなどの Data Factory リソースを作成するためのアクセス許可が必要です。
開発者は変更を行う目的で機能ブランチを作成します。 署名付きコミットは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」は「パイプライン1」よりも好ましい名前です。
リポジトリの変更。 Azure Data Factory(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ファイルを使ってサポートされた展開機構に切り替えてください。