この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

はじめに

訳有ってアプリケーション構築経験の無いインフラエンジニアがAzureDevOpsを使用してアプリケーションデプロイ方法を検証する必要が生じた為、掲題のパイプラインにおける承認機能を入れるにあたり初心者なりに躓いたポイントを整理したいと思います。AzureDevOpsを使いこなしている方からすると当たり前の内容になりますがご容赦下さい。

基本方針

少し検索してみると承認の機能を入れるためにはAzureDevOpsのEnvironmentという機能を使用すれば良いことが分かります。そこでEnvironmentの設定をしつつ、CICDの実行に使用するyamlファイルに記述を追加してパイプラインにてEnvironmentの設定を利用できるようにすることとなります。

前提条件

本記事では以下を前提として記述しています。
・AzureDevOpsの環境が準備済みであること。
・AzureDevOpsのReposにソースが格納済みであること。

Environmentの設定

まずはEnvironmentを設定します。AzureDevOpsにログインし該当プロジェクトを選択後に「Pipelines」-「Environments」と遷移し、「New environment」を選択します。

Name欄に任意の名称を入力し、「Create」を押下します。承認機能としてのみ使用するため、「Resouce」は「None」のままで問題ありません。

右上の縦三点リーダーを押下し、「Approvals and checks」を押下します。

右上の「＋」を押下します。

 

「Approvals」にチェックを入れ、「Next」を押下します。

「Approvers」欄にて承認者としたいユーザーを入力し、「Create」を押下します。ここでは複数のユーザを選択することもできます。また、1点注意点としてどうやらAzure DevOpsの当該プロジェクトの権限を持っていないアカウントもAzureDevOps組織上のアカウントであれば選択できるようでした。ただそのようなアカウントをここで選択したとしても、実際に承認する際に当該プロジェクトの画面にアクセスできない為、誤って追加しないようしましょう。

Approvalが追加されました。

yamlファイルの修正と動作確認

Environmentを使用する為にはパイプラインの定義されたyamlファイルに「environment」のパラメータを追記します。今回はデプロイステージに追加しました。
ここで一つ注意点が有ります。「environment」を使用しないでパイプラインを定義する場合は以下画像の110行目の「deployment」という記述を「job」としておく必要が有ります。つまり「environment」を使用するかどうかで構文が変わってしまうので、ただ「environment」パラメータを追加するだけでは不十分ということになります。

yamlファイルを修正したうえでパイプラインを実行するとパイプラインの実行画面にて以下画像のように承認のための「Review」ボタンが表示されますの押下します。また、承認者に設定されているアカウントにはメールが通知されます。以下はサンプルとして一つのパイプラインで合計4つのアプリケーションをデプロイするように定義しており、ステージをビルド、開発環境リリース、本番環境リリースの3つに分け本番環境リリースの際に承認を挟んでいます。承認されないと処理が進まない為、各ステージに「waiting」と表示されています。

承認対象のステージごとに「Approve」もしくは「Reject」を押下し、承認もしくは拒否します。勿論ここで承認した対象のみ後続処理が進みます。

検証してみて気づいた点

検証してみて以下の点は気を付けておくべき点かと思いました。
①environmentに複数人を指定した場合は指定した全員の承認が無いと処理が進まない。
②environmentにて承認者を誰も指定していない場合は承認を介さずに後続処理が進む。

①の点から、誰か一人承認すれば処理が進むというわけでは無い為、複数人指定しておくことで誤ってリリースするようなことを防ぎやすい一方で、既に当該プロジェクトにアクセス権の無いユーザが指定されたままenvironmentの設定が更新されていないといつまでたってもリリースされないということになります。

また、②の点からはEnvironmentの設定のみを追加したものの承認者を設定し忘れていると承認を介さずリリースされてしまう為、こちらも要注意です。一方で上述した通りyamlファイルにenvironmentのパラメータを追加する場合は、「job」パラメータの代わりに「deployment」パラメータを使用する必要が有りますが、誰も承認者が設定されていないEnvironmentの設定を使用すれば承認を設定するか否かで構文を変える必要が無くなるということにもなりますので、一応メリットもあると言えそうです。

最後に

本記事はこれで以上となりますが、気づいた点に記載したことからもAzureDevOps組織におけるアカウントの権限管理(勿論AzureDevOpsに限った話ではありませんが)がやはり重要なのだと感じました。