Azure Pipelinesを使用したCICDベースラインアーキテクチャ実践

2024/07/16（水）にJapan Azure Users Groupで登壇させて頂いた際の資料です。

1. Azure Pipelinesを使用したCI/CDベー スラインアーキテクチャ実践 2024/7/16 yuriemori, yutakaosada
2. Agenda  Introduction  今日話すこと  自己紹介  クラシックパイプライン以降のAzure Pipelinesの構成プラクティス  さよならクラシックパイプライン  主な変更点  変更後のYAMLベースのパイプラインのメリット  ベースラインアーキテクチャをもとにしたYAMLベースでのAzure Pipelines構築  YAMLベースでのパイプラインの実装とデプロイ計画  Demo  PR/CI/CDパイプライン  Azure Key Vaultに格納したシークレットをパイプラインから参照する  EnvironmentのApprovals&Checksによるデプロイターゲット環境へのデプロイの承認  まとめ
3. Introduction
4. 今日話すこと  クラシックパイプライン非推奨後のAzure Pipelinesの変更点  Azure Pipelinesのベースラインアーキテクチャに沿った構成とデプロイの制御  YAMLでのマルチステージパイプラインの構成  Azure Key Vaultを利用したパイプラインで使用するシークレットの管理
5. Yurie Mori（森 友梨映）  DevOps Engineer @Avanade Japan  お仕事  AgileとDevOpsの実践の支援  DevOpsソリューション（ Azure DevOps/GitHub ）の導入・構築  GenAI assisted with SDLC  技術スタック  Azure DevOps, GitHub, Azure, .NET, C#  Please follow me
6. Yutaka Osada（⾧田 豊）  DevOps Engineer @Avanade Japan  お仕事  Azureコンポーネントを活用したサービス構築  技術検証、パフォーマンスチューニングを得意とし、T-SQLが好き。  技術スタック  C#, .NET, Azure(PaaS), Azure DevOps, Sitecore  Please follow me
7. クラシックパイプライン以降のAzure Pipelinesの構成プラクティス
8. さよならクラシックパイプライン  2023年1月にAzure DevOpsでクラシックパイプラインの作成を禁止するリリー スが発表されました。  2023年3月以降に作成されるOrganizationではクラシックパイプラインの作成 はデフォルトでは無効になっており、YAMLベースのパイプライン構成が推奨と なります。 これが使えなくなります
9. 主な変更点（1/2） クラシックリリースパイプライン無効後の Azure Pipelinesメニュー クラシックリリースパイプライン無効前の 組織のAzure Pipelinesメニュー GUIベースでパイプラインの作成 をサポートしていたこれらのメ ニューが消滅 パイプラインはビルド/リリース問わず YAMLファイルで構成するように
10. （最新）YAMLベースでのパイプラインで の代替手段 クラシックリリース パイプライン クラシックビルド パイプライン 概要 機能 Environmentでデプロイターゲットを指定 〇 × デプロイターゲットマシンの論理 セットを定義 デプロイグループ YAMLでデプロイジョブを定義 〇 × デプロイグループにリリースする ジョブを指定 デプロイグループ ジョブ EnvironmentでのApprovals&Checksを使用 〇 × リリースステージを完了する前の 外部の正常性シグナルの自動収集 と評価をサポート（アプリケー ションを特定の環境にデプロイす る前のチェック） リリースゲート YAMLファイルで再利用したいタスク群を テンプレートファイルとして定義する 〇 〇 一連のタスクを再利用可能な1つ のタスクにカプセル化 タスクグループ 主な変更点（2/2） クラシックパイプラインで使用できた機能で使えなくなるものたちとYAMLベースパイプラインでの代替手段
11. 変更後のYAMLベースのパイプラインのメリット  パイプラインをソースコードと同様にバージョン管理できる  YAMLファイルはソースコードと同じリポジトリで管理できるため、変更履歴を追跡し やすく、過去のバージョンに簡単に戻すことができる。  レビューが容易になる  ソースコードと同様に、変更をマージするためにPRを強制することで、悪意のある行 為者がパイプラインに悪意のあるステップを導入するのを防ぐことができる（ブランチ ポリシーを使用することでPRの強制ができる）  リソースアクセス管理が可能  リソース所有者は、YAML パイプラインがリソースにアクセスできるかどうかを制御で き、別のリポジトリを盗むなどの攻撃の防止が可能となる。  承認とチェックにより、パイプラインの実行ごとに機能するアクセス制御が提供される。  セキュリティの向上  シークレットの露出防止: シークレットや機密情報をパイプラインファイルにハード コーディングすることなく、Azure Key Vaultなどのシークレット機構に格納された情報 をランタイムパラメーターとして動的に渡すことができるため、リポジトリに機密情報 が含まれるリスクの軽減が可能となる。 参考:https://devblogs.microsoft.com/devops/disable-creation-of-classic-pipelines/
12. ベースラインアーキテクチャをもとにしたYAMLベー スでのAzure Pipelines構築 参考:https://learn.microsoft.com/ja-jp/azure/devops/pipelines/architectures/devops- pipelines-baseline-architecture?view=azure-devops
13. demo
14. デモでお見せするもの  PR/CI/CDパイプライン  Azure Key Vaultに格納したシークレットをパイプラインから参照する  EnvironmentのApprovals&Checksによるデプロイターゲット環境へのデプロイの承認 ベースラインアーキテク チャのここの部分
15. demo architecture Azure Azure DevOps Managed Id App Service Dev Env App Service Staging Env Azure Repos Azure Pipelines Environments Library Pipelines PR Pipeline CI/CD Pipeline Key Vaultよりシークレット情報 を取得 Completed 1 2 5 4 Defender for Cloud DevOps Key Vault Secret Environmentsに定義した環境に対応する App Serviceに対する承認チェック Analize stageによる セキュリティチェック Azure DevOps for Workload identity 承認プロセスが構成された環境へのデプロイは、 承認者からの承認されるまで実行されない Pull request Approved 3 Developer Reviewer Service connection 6 7 Pull Request作成時にPR Pipelineを起動
16. ☆ポイント  AzDO⇔Azure間接続 サービスコネクション（workload identity）  Pipelines Library（Key Vaultへの接続）  Pipelines Environments（デプロイターゲットの定義）  PR・CI/CD Pipelinesの構築  パイプラインの実行許可  Approvalチェックの指定  ブランチポリシーへPRパイプラインを指定  ソースコード変更し、Pull Request PR パイプラインを起動  ソースコードApprove→CI/CD起動→完了後タブの説明
17. ベースラインアーキテクチャをもとにしたYAMLベースでの Azure Pipelines構築 – PR Pipeline  PR Pipelines  PR作成をトリガーとするパイプライン  以下を実行  コード解析（Linterによるフォーマットチェック、静的コード解 析によるセキュリティチェック）  依存関係の回復  ビルド  単体テストの実行  PR作成時に上記の様々なチェック/テストを実行するため、 レビュアーのレビュー負担を軽減することができる  これらの処理が失敗した場合、PRはマージできないため、問 題のあるソースコードが⾧命ブランチに混入するのを早期に 防ぐことができる PR作成をトリガーにするこのパ イプラインのみ、トリガーは チェック対象のブランチ設定 >Build Validationで設定する
18.  CI Pipelines  特定のブランチへのpushをトリガーとするパイプライン  以下を実行  PR Pipelineで実行していた処理内容  + 結合テスト/UIテスト（ここで使用するシークレットをAzure Key Vaultから参照してテストを実 行）  ビルド成果物の発行  ソースコードをリリース可能な状態にする  CD Pipeline  ビルド成果物のダウンロード  受入テスト  各環境へのデプロイを実行する  本番環境など重要な環境へのデプロイに関してはApprovals & Checksでデプロイ前の承認を 構成する（クラシックリリースパイプラインにおけるリリースゲートの役割） これらのCI,CD Pipelineは1つのYAMLファイルでマルチステージパイプラインとして構成 する（CDを分けるとエージェントが異なってしまうのでCIで作成した成果物のDLができ ない） ベースラインアーキテクチャをもとにしたYAMLベースでの Azure Pipelines構築 – CI,CD Pipeline
19. 見せられないよ Azure Key Vaultへのサービスコ ネクションの名称を指定 Azure Key Vaultの名称を指定 Azure Key Vaultで格納されてい るシークレットの名称 ベースラインアーキテクチャをもとにしたYAMLベースでのAzure Pipelines構築 - パイプラインで使用するAzure Key Vaultのシークレットの設定
20. Pipelines>Environmentでデプロ イする環境を指定 重要な環境へのデプロイの前に 承認プロセスを設定し、意図し ないデプロイを防ぐ ベースラインアーキテクチャをもとにしたYAMLベースでの Azure Pipelines構築 - デプロイ環境の定義と承認の構成(1/2)
21. 承認プロセスが構成された環境 へのデプロイは、承認者からの 承認されるまで実行されない 承認者に対してはデプロイの直 前にこんな感じで承認してくだ さい通知がいく ベースラインアーキテクチャをもとにしたYAMLベースでの Azure Pipelines構築 - デプロイ環境の定義と承認の構成(2/2)
22. ポイント  クラシックパイプラインからYAMLベースのパイプラインへ  クラシックパイプラインでビルドパイプライン/リリースパイプラインとして 構成していたものはYAMLファイルでCI, CDの複数のステージを定義するマルチ ステージパイプラインとして実装する  クラシックリリースパイプラインでのリリースゲート（リリース前の承認ゲー ト）はEnvironmentでApprovals & Checksで構成する  パイプライン内で使用するシークレットはLibraryでAzure Key Vaultを参照する ように設定する
23. まとめ
24. まとめ  YAMLベースでパイプラインを作成することにより、パイプラインのバージョ ン管理とレビューが容易になる  Azure Key Vaultを使用することでセキュアにCI/CDを実現  クラシックのビルド/リリースパイプライン→YAMLファイルでマルチステージ パイプラインを構成（ので、ビルドパイプラインとかリリースパイプラインと いう概念はもはやなくなる?）  デプロイ前の承認プロセスを構成することにより、重要な環境への意図しない デプロイを防ぐことができる
25. [Microsoft Learn - Azure Pipelinesのベースラインアーキテクチャ] https://learn.microsoft.com/ja-jp/azure/devops/pipelines/architectures/devops-pipelines-baseline-architecture?view=azure- devops [Microsoft Learn - YAMLパイプラインとクラシックビルド、リリース パイプラインの機能一覧] https://learn.microsoft.com/ja-jp/training/modules/create-release-pipeline-devops/2-describe-azure-devops-capabilities [Microsoft Learn - 承認とチェックを定義する] https://learn.microsoft.com/ja-jp/azure/devops/pipelines/process/approvals?view=azure-devops&tabs=check-pass [Microsoft Learn - Azure DevOps を使用してマルチステージ パイプラインを作成する] https://learn.microsoft.com/ja-jp/azure/devops/pipelines/process/create-multistage-pipeline?view=azure-devops デモで利用したSrcは下記に配置しています。 https://github.com/yutaka-art/Baseline_Architectures References
26. クラシックパイプラインの非推奨に伴うAZ-400のラーニングパスの参照すべきドキュメントの変更点一覧は以下の記事に記 載しています。 https://zenn.dev/yuriemori/articles/0eee4d3713aa18 References