継続的インテグレーションと継続的配置

8 分

継続的インテグレーションは、コードベースに対して行われた変更を、できるだけ早く自動的にテストするプラクティスです。継続的デリバリーは、継続的インテグレーションの間に発生したテストに続けて、変更をステージングまたは実稼働システムにプッシュします。

Azure Data Factory では、継続的インテグレーションと継続的デリバリー (CI/CD) とは、Data Factory パイプラインをある環境 (開発、テスト、運用) から別の環境に移動することを意味します。 Azure Data Factory では Azure Resource Manager テンプレートを活用し、さまざまな Azure Data Factory エンティティ (パイプライン、データセット、データフローなど) の構成を格納します。データファクトリを別の環境に昇格させる手法が 2 つ提案されています。

Data Factory と Azure Pipelines の統合を利用した自動化されたデプロイ。
Data Factory UX と Azure Resource Manager の統合を利用した Resource Manager テンプレートの手動アップロード。

継続的インテグレーションと継続的デリバリーのライフサイクル

Azure Repos Git で構成された Azure Data Factory での CI/CD のライフサイクルのサンプル概要を以下に示します。

Azure Repos Git で開発データファクトリが作成され、構成されます。すべての開発者には、パイプラインやデータセットなどの Data Factory リソースを作成するためのアクセス許可が必要です。
開発者は変更を行う目的で機能ブランチを作成します。一番新しい変更を利用し、パイプライン実行をデバッグします。
開発者は、変更の結果に問題がなければ、各自の機能ブランチからマスターまたはコラボレーションブランチへの pull request を作成して、同僚が変更をレビューできるようにします。
pull request が承認され、変更がマスターブランチにマージされたら、変更が開発ファクトリに発行されます。
チームは、変更をテストまたは UAT (ユーザー受け入れテスト) ファクトリにデプロイする準備ができたら、Azure Pipelines リリースに進み、望ましいバージョンの開発ファクトリを UAT にデプロイします。このデプロイは Azure Pipelines タスクの一環として行われ、Resource Manager テンプレートパラメーターを使用し、適切な構成を適用します。
テストファクトリで変更の妥当性が確認されたら、パイプラインリリースの次のタスクを利用し、運用環境のファクトリにデプロイします。

Note

開発ファクトリのみ、Git リポジトリに関連付けられます。テストファクトリと運用環境のファクトリには Git リポジトリを関連付けません。更新には必ず Azure DevOps パイプラインか Resource Management テンプレートを利用してください。

下の図は、このライフサイクルのさまざまなステップを示しています。

Diagram of continuous integration with Azure Pipelines

Azure Pipelines リリースを使用して継続的インテグレーションを自動化する

以下は、Azure Pipelines リリースを設定し、複数の環境へのデータファクトリのデプロイを自動化するためのガイドです。

必要条件

Azure Resource Manager サービスエンドポイントを使用する Visual Studio Team Foundation Server または Azure Repos にリンクされた Azure サブスクリプション
Azure Repos Git 統合で構成されたデータファクトリ。
各環境用のシークレットを格納する Azure Key Vault。

Azure Pipelines リリースをセットアップする

Azure DevOps で、データファクトリで構成したプロジェクトを開きます。
ページの左側で、 [パイプライン] を選択して [リリース] を選択します。
[新しいパイプライン] を選択するか、既存のパイプラインがある場合は [新規] 、 [新しいリリースパイプライン] の順に選択します。
[空のジョブ] テンプレートを選択します。
[ステージ名] ボックスに、環境の名前を入力します。
[成果物の追加] を選択し、開発データファクトリで構成した Git リポジトリを選択します。既定のブランチのリポジトリの発行ブランチを選択します。既定では、この発行ブランチは adf_publish です。 [既定のバージョン] では [既定のブランチからの最新バージョン] を選択します。
Azure Resource Manager デプロイタスクを追加します。

a. ステージビューで、 [ステージタスクを表示します] を選択します。

b. 新しいタスクを作成します。 [ARM テンプレートのデプロイ] を探して [追加] を選択します。

c. デプロイタスクでは、ターゲットのデータファクトリのサブスクリプション、リソースグループ、および場所を選択します。必要であれば資格情報を指定します。

d. [Action](アクション) 一覧で、 [Create or update resource group](リソースグループの作成または更新) を選択します。

e. [テンプレート] ボックスの横にある省略記号ボタン ( […] ) を選択します。構成されている Git リポジトリの発行ブランチで生成される Azure Resource Manager テンプレートを参照します。ファイル ARMTemplateForFactory.json は adf_publish ブランチの <FactoryName> フォルダーで探します。

f. [テンプレートパラメーター] ボックスの横にある … を選択して、パラメーターファイルを選択します。ファイル ARMTemplateParametersForFactory.json は adf_publish ブランチの <FactoryName> フォルダーで探します。

g. [テンプレートパラメーターのオーバーライド] ボックスの横にある … を選択して、ターゲットのデータファクトリに望ましいパラメーター値を入力します。 Azure Key Vault から取得した資格情報の場合は、シークレットの名前を二重引用符で囲んで入力します。たとえば、シークレットの名前が cred1 の場合は、この値に「 "$ (cred1)" 」と入力します。

h. [配置モード] で [Incremental](増分) を選択します。

警告

完全なデプロイモードでは、リソースグループに存在していても、新しい Resource Manager テンプレート内で指定されていないリソースは、削除されます。
リリースパイプラインを保存します。
リリースをトリガーするには、 [Create release](リリースの作成) を選択します。 Azure DevOps では、これを自動化できます。

重要

CI/CD のシナリオでは、異なる環境内の統合ランタイム (IR) の種類は同じである必要があります。たとえば、開発環境にセルフホステッド IR がある場合、テストや運用などの他の環境でも、IR の種類はセルフホステッドである必要があります。同様に、複数のステージ間で統合ランタイムを共有している場合は、開発、テスト、運用など、すべての環境で、統合ランタイムをリンクされたセルフホステッドとして構成する必要があります。

Azure Key Vault からシークレットを取得する

Azure Resource Manager テンプレートに渡すシークレットがある場合は、Azure Pipelines リリースで Azure Key Vault を使うことをお勧めします。

シークレットを処理する方法は 2 つあります。

シークレットをパラメーターファイルに追加します。

発行ブランチにアップロードされたパラメーターファイルのコピーを作成します。次の形式を使用して、Key Vault から取得するパラメーターの値を設定します。
```
{
    "parameters": {
        "azureSqlReportingDbPassword": {
            "reference": {
                "keyVault": {
                    "id": "/subscriptions/<subId>/resourceGroups/<resourcegroupId> /providers/Microsoft.KeyVault/vaults/<vault-name> "
                },
                "secretName": " < secret - name > "
            }
        }
    }
}
```
このメソッドを使用すると、シークレットはキーコンテナーから自動的にプルされます。

パラメーターファイルも発行ブランチ内に存在する必要があります。
前のセクションで説明されている Azure Resource Manager デプロイタスクの前に、Azure Key Vault タスクを追加します。
1. [タスク] タブで、新しいタスクを作成します。 Azure Key Vault を検索して追加します。
2. Key Vault タスクで、キーコンテナーを作成したサブスクリプションを選択します。必要に応じて資格情報を入力し、キーコンテナーを選択します。

Azure Pipelines エージェントにアクセス許可を与える

適切なアクセス許可が設定されていない場合、Azure Key Vault タスクがアクセス拒否エラーで失敗することがあります。リリースのログをダウンロードし、Azure Pipelines エージェントにアクセス許可を与えるコマンドを含む .ps1 ファイルを探します。コマンドは直接実行できます。または、ファイルからプリンシパル ID をコピーし、Azure portal でアクセスポリシーを手動で追加できます。必要な最低限のアクセス許可は、Get と List です。

アクティブなトリガーを更新する

アクティブなトリガーを更新しようとした場合、デプロイは失敗します。アクティブなトリガーを更新するには、手動でそれらを停止し、デプロイ後に再起動する必要があります。これは、Azure Powershell タスクを使用して実行できます。

リリースの [タスク] タブで、 [Azure PowerShell] タスクを追加します。タスクバージョン 4.* を選択します。
お使いのファクトリがあるサブスクリプションを選択します。
スクリプトの種類として [スクリプトファイルパス] を選択します。これにより、リポジトリへの PowerShell スクリプトの保存が求められます。次の PowerShell スクリプトを使用すると、トリガーを停止できます。
```
$triggersADF = Get-AzDataFactoryV2Trigger -DataFactoryName $DataFactoryName -ResourceGroupName $ResourceGroupName

$triggersADF | ForEach-Object { Stop-AzDataFactoryV2Trigger -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_.name -Force }
```

(Start-AzDataFactoryV2Trigger 関数を使用して) 同様の手順を実行することで、デプロイ後にトリガーを再起動できます。

注意

これらの手順は、Azure Data Factory チームによって提供される配置前および配置後スクリプトに既に含まれています

各環境用の Resource Manager テンプレートを手動でプロモートする

Azure DevOps や別のリリース管理ツールを使用できない場合は、ARM テンプレートを使ってデータファクトリを手動で昇格させることができます。

[ARM テンプレート] 一覧から、 [ARM テンプレートのエクスポート] を選択して、データファクトリ用の Resource Manager テンプレートを開発環境にエクスポートします。
テストおよび運用データファクトリで、 [Import ARM template](ARM テンプレートのインポート) を選択します。このアクションによって Azure Portal に移動して、エクスポートされたテンプレートをインポートできます。 [Build your own template in the editor](エディターで独自のテンプレートを作成する) を選択して、Resource Manager テンプレートエディターを開きます。
[ファイルの読み込み] を選択し、生成された Resource Manager テンプレートを選択します。これは、手順 1 でエクスポートした .zip ファイルに格納されている arm_template.json ファイルです。
設定セクションで、リンクされたサービスの資格情報などの構成値を入力します。完了したら、 [購入] を選択して Resource Manager テンプレートをデプロイします。

Azure Resource Manager テンプレートのパラメーターをカスタマイズする

開発ファクトリに Git リポジトリが関連付けられている場合、テンプレートの公開やエクスポートによって生成された Resource Manager テンプレートの既定の Resource Manager テンプレートパラメーターをオーバーライドすることができます。既定のパラメーター化のテンプレートは、以下のシナリオでオーバーライドすることもできます。

自動化された CI/CD を使用していて、Resource Manager のデプロイ中にいくつかのプロパティを変更したいが、プロパティが既定でパラメーター化されていない。
ファクトリが非常に大きく、既定の Resource Manager テンプレートが許容されるパラメーターの上限 (256) よりも多いために無効である。

既定のパラメーター化テンプレートをオーバーライドするには、管理ハブにアクセスし、ソース管理セクションの [パラメーター化テンプレート] を選択します。 [テンプレートの編集] を選択して、パラメーター化テンプレートコードエディターを開きます。

Manage custom parameters

カスタムパラメーター化テンプレートでは、Git ブランチのルートフォルダーに arm-template-parameters-definition.json という名前のファイルが作成されます。正確なファイル名を使用する必要があります。

Custom parameters file

コラボレーションブランチから発行すると、Data Factory では、このファイルを読み取り、その構成を利用してパラメーター化するプロパティが生成されます。ファイルが見つからない場合は、既定のテンプレートが使用されます。

Resource Manager テンプレートをエクスポートすると、Data Factory により、コラボレーションブランチでなく、現在作業中のどのブランチからでもこのファイルを読み取られます。プライベートブランチからファイルを作成または編集し、UI の [ARM テンプレートのエクスポート] を選択して変更内容をテストすることができます。その後、このファイルをコラボレーションブランチ内にマージできます。

Note

カスタムパラメーター化テンプレートでは、ARM テンプレートパラメーターの制限である 256 が変更されることはありません。これにより、パラメーター化されたプロパティの数を選択して減らすことができます。

カスタムのパラメーター構文

カスタムパラメーターファイル arm-template-parameters-definition.json を作成する際のいくつかのガイドラインを次に示します。ファイルは、(トリガー、パイプライン、リンクされたサービス、データセット、統合ランタイム、データフロー) エンティティの種類ごとのセクションで構成されています。

関連するエンティティ型の下にプロパティパスを入力します。
プロパティ名を * に設定すると、その下 (再帰的にではなく、最初のレベルまでのみ) にあるすべてのプロパティをパラメーター化することを指示します。また、この構成に例外を指定することもできます。
プロパティの値を文字列として設定すると、プロパティをパラメーター化することを指示します。「<action>:<name>:<stype>」の形式を使用します。
- <action> には、次のいずれかの文字を指定できます。
  - = は、パラメーターの既定値として現在の値を保持することを意味します。
  - - は、パラメーターの既定値を保持しないことを意味します。
  - | は、接続文字列またはキーに対する Azure Key Vault からのシークレットの特殊なケースです。
- <name> は、パラメーターの名前です。空白の場合は、プロパティの名前になります。値が - 文字で始まる場合、名前は短縮されます。たとえば、AzureStorage1_properties_typeProperties_connectionString は AzureStorage1_connectionString に短縮されます。
- <stype> は、パラメーターの型です。 <stype> が空白の場合、既定の型は string です。サポートされる値は string、bool、number、object、securestring です。
定義ファイルに配列を指定すると、テンプレート内の一致するプロパティが配列であることを指示します。 Data Factory は、配列の統合ランタイムオブジェクトに指定された定義を使用することで、配列内のすべてのオブジェクトを反復処理します。 2 番目のオブジェクトである文字列は、各反復処理のパラメーターの名前として使用されるプロパティ名です。
定義をリソースインスタンスに固有にすることはできません。定義はその型のすべてのリソースに適用されます。
既定では、Key Vault シークレットなどのセキュリティで保護されたすべての文字列と、接続文字列、キー、トークンなどのセキュリティで保護された文字列がパラメーター化されます。

リンク済みテンプレート

データファクトリの CI/CD を設定済みの場合、ファクトリが大規模になるにつれて Azure Resource Manager テンプレートの制限を超える可能性があります。たとえば、1 つの制限として、Resource Manager テンプレート内のリソースの最大数があります。ファクトリ用の完全な Resource Manager テンプレートを生成しながら、大規模なファクトリに対応するために、Data Factory では、リンクされた Resource Manager テンプレートが生成されるようになりました。この機能を使用すると、ファクトリのペイロード全体が複数のファイルに分割されるので、制限によって制約されることはありません。

Git を構成した場合は、リンクされたテンプレートが生成され、完全な Resource Manager テンプレートと共に、adf_publish ブランチの linkedTemplates という名前の新しいフォルダーに保存されます。通常、リンクされた Resource Manager テンプレートは、マスターテンプレートと、マスターにリンクされた一連の子テンプレートで構成されます。親テンプレートは ArmTemplate_master.json という名前になり、子テンプレートには、ArmTemplate_0. json、ArmTemplate_1.json といったパターンで名前が付けられます。

完全な Resource Manager テンプレートではなく、リンクされたテンプレートを使用するには、ArmTemplateForFactory.json (完全な Resource Manager テンプレート) ではなく ArmTemplate_master.json をポイントするように CI/CD タスクを更新します。 Resource Manager では、リンクされたテンプレートをストレージアカウントにアップロードして、デプロイ時に Azure によってアクセスできるようにする必要もあります。

運用環境への修正プログラムの適用

ファクトリを運用環境にデプロイし、すぐに修正が必要なバグがあることが判明したが現在のコラボレーションブランチをデプロイできない場合、修正プログラムのデプロイが必要なことがあります。この方法は、クイック修正エンジニアリングまたは QFE と呼ばれています。

Azure DevOps で、運用環境にデプロイされたリリースに移動します。デプロイされた最後のコミットを見つけます。
コミットメッセージから、コラボレーションブランチのコミット ID を取得します。
そのコミットから新しい修正プログラムブランチを作成します。
Azure Data Factory UX に移動し、修正プログラムブランチに切り替えます。
Azure Data Factory UX を使用して、バグを修正します。変更をテストします。
修正が検証されたら、 [ARM テンプレートのエクスポート] を選択して、修正プログラムの Resource Manager テンプレートを取得します。
このビルドを発行ブランチに手動でチェックインします。
adf_publish のチェックインに基づいて自動的にトリガーするようにリリースパイプラインを構成している場合、新しいリリースは自動的に開始します。それ以外の場合は、手動でリリースをキューに配置します。
テストと運用ファクトリに修正プログラムリリースをデプロイします。このリリースには、以前の運用ペイロードに加えて、手順 5 で行った修正が含まれています。
修正プログラムでの変更を開発ブランチに追加して、今後のリリースに同じバグが含まれないようにします。

継続的インテグレーションと継続的デリバリーのベストプラクティス

データファクトリとの Git 統合を使用していて、変更を開発からテストを経て運用環境に移行する CI/CD パイプラインがある場合は、次のベストプラクティスをお勧めします。

Git 統合。 Git 統合で開発データファクトリのみを構成します。テスト環境と運用環境への変更は CI/CD を介してデプロイされるので、Git 統合は必要ありません。
デプロイ前とデプロイ後のスクリプト。 CI/CD の Resource Manager のデプロイ手順の前に、トリガーの停止と再起動やクリーンアップの実行など、特定のタスクを完了する必要があります。デプロイタスクの前後に PowerShell スクリプトを使用することをお勧めします。データファクトリチームにより、使用するスクリプトが Azure Data Factory CI/CD のドキュメントページで提供されています。
統合ランタイムと共有。統合ランタイムは頻繁には変更されず、CI/CD のすべてのステージで類似しています。そのため、Data Factory では、CI/CD のすべてのステージで統合ランタイムの名前と種類を同じにすることが求められます。すべてのステージで統合ランタイムを共有する場合は、共有の統合ランタイムを含めるためだけに三項ファクトリを使用することを検討してください。この共有ファクトリは、すべての環境で、リンクされた統合ランタイムの種類として使用できます。
マネージドプライベートエンドポイントデプロイ。プライベートエンドポイントがファクトリに既に存在している場合、同じ名前と変更されたプロパティを持つプライベートエンドポイントを含む ARM テンプレートをデプロイしようとすると、デプロイが失敗します。つまり、既にファクトリに存在するものと同じプロパティを持つ限り、プライベートエンドポイントを正常にデプロイできます。環境によってプロパティが異なる場合は、そのプロパティをパラメーター化し、デプロイ時にそれぞれの値を指定することでオーバーライドできます。
Key Vault。リンクされているサービスを使用するとき、その接続情報が Azure Key Vault に格納されている場合、キーコンテナーを環境別に保持することが推奨されます。キーコンテナーごとに個別のアクセス許可レベルを構成することもできます。たとえば、運用環境のシークレットへのアクセス許可をチームメンバーに持たせたくない場合があります。このアプローチに従う場合は、すべてのステージで同じシークレット名を保持することをお勧めします。同じシークレット名を保持する場合、CI/CD 環境全体で各接続文字列をパラメーター化する必要はありません。変わるのは別個のパラメーターであるキーコンテナーの名前だけだからです。
リソースの名前付け ARM テンプレートの制約により、リソースの名前にスペースが含まれていると、デプロイで問題が発生する可能性があります。 Azure Data Factory チームは、リソースではスペースの代わりに "_" または "-" 文字を使用することをお勧めします。たとえば、"Pipeline 1" ではなく "Pipeline_1" という名前を使用します。

続行