Azure DevOpsで承認アクションを実装してみた
前回の記事「Azure DevOpsを触ってみた」では、Azure DevOpsの機能を体験するために、DevOps Startarを利用して、Azure DevOpsでのCI/CDがどのようなものかを確認しました。
今回は、開発環境とは別の環境(例えば本番環境やQA環境)へリリースする際に承認を必要とするような承認アクションをパイプラインに実装してみます。
併せて、App Serviceでデプロイ スロットを実装し、スロットのスワップ機能も試してみます。
プロジェクト名等は、以下のように設定しました。
次に、App Serviceでデプロイ スロットを利用できるプランに変更します。
アプリのApp Serviceプランが「S1」ではない場合は、「S1」に変更してください。（注）
変更手順は、以下のURL先にある「アプリを別の App Service プランに移動する」をご参照ください。
https://docs.microsoft.com/ja-jp/azure/app-service/app-service-plan-manage
（注）：デプロイ スロットを利用できるようにするためには、App ServiceのプランをStandard以上にする必要があります。課金が発生しますので、検証される際は注意してください！
プランの変更後、新ためてApp Serviceの画面に移動します。
左側メニューの「デプロイ スロット」をクリックします。
デプロイ スロットが追加されていない旨のメッセージが表示されていますね。
早速、デプロイ スロットの追加を行いましょう。
「スロットの追加」をクリックします。
「スロットの追加」が画面右側に表示されます。ここでは設定を引き継ぐことができます。
設定後、画面下の「追加」をクリックしてください。
これでデプロイ スロット「qesflow001-qa」が追加されます。
今回は、「qesflow001」を開発環境、「qesflow001-qa」をQA環境と見立てて、フローを作成したいと思います。
まずは、「qesflow001」のAzure DevOps メイン画面を表示させましょう。
そのメイン画面で、「Pipelines」 - 「Releases」をクリックします。
クリック後、画面右側で、今回作成したプロジェクトを選択した状態で、
画面右上の「Edit」をクリックします。
Edit画面に移りました。
「Stages」配下の「dev」上にマウスカーソルを置くと、コピーのアイコンが表示されます。
このアイコンをクリックしてください。これで、既存のStageをクローンできます。
クローンが完了したら、クローンしたStageの名前を「QA」と変更しましょう。
次に、「QA」stageの設定を変更します。
「QA」stageの「1 job, 4 tasks」のリンクをクリックします。
その後、「Deploy Azure App Service」をクリックします。画面右側に細かい設定項目が表示されます。
この中にある、「Deploy to slot」のチェックボックスをクリックしてみましょう。
「Slot」には先ほど作成した「qa」を指定します。
最後に、画面上部の「Save」をクリックし、適宜コメントを書いてからOKをクリックします。
これで、本stageのデプロイ先が、デプロイ スロットである「qa」に設定されました。
一度、Releasesの動作を確認してみましょう。
前回の記事のように、「index.cshtml」ファイルを修正し、パイプラインを流してみます。
両方の環境とも、htmlファイルの変更が反映されていることが確認できました。
（今回、「Success！」を「Success Hello!!」に変更しました）
■開発環境(URLがhttps://qesflow001.azurewebsite.net)
■QA環境(URLがhttps://qesflow001-qa.azurewebsite.net)
リリースの追加も完了しましたので、次は承認アクションを追加します。
再度、プロジェクトのEdit画面に移りましょう。
そして、赤枠で囲ったアイコンをクリックしてください。
「QA」Stageが実行される前提条件を設定することができます。
ここで、承認者に指定した担当者がOKをしない限り「QA」Stageが実行されないように設定できます。
「Pre-deployment approvals」欄に、承認者を設定します。
今回は自分自身を設定してみましょう。
自分のAzureアカウントに設定しているメールアドレスを入力して、承認者を設定します。
設定できましたら、画面上部の「Save」をクリックします。
これで、「QA」Stage処理前に、承認者に指定された担当者が承認を行わないと「QA」Stageの処理が行われないようになりました。
以下のように、「QA」Stageの下に「Approve」というボタンがありますね。
このボタンをクリックすれば、「QA」Stageの処理が実行されるようになります。
では、「Approve」ボタンをクリックします。
すると、以下の画面が表示されます。
適宜、コメントを残し、「Approve」ボタンをクリックします。
ボタンクリック後、「QA」stageの処理が実行されます。
以下のような画面が表示されましたね。
これで、無事に承認作業が完了しました。
閉じるボタンをクリックして、この画面を閉じます。
以下のように、「QA」stageの処理が実行されています！
しかし、実際の環境においては、同一アプリ内に、STG環境と本番環境があるとして、STG環境に修正モジュールをリリース、動作確認で問題がなければそのままスワップ処理を実行して、STG環境と本番環境を入れ替える、といった実装のほうが望ましいのではないでしょうか。
せっかくなので、最後にApp Serviceのスロット スワップの動作確認を行いたいと思います。
今回作成したApp Serviceには2スロット分の環境があります。
スワップ処理の実行結果がわかるように、
環境１(https://qesflow001.azurewebsites.net)では、「Success Hello Again!!!」と、環境2(https://qesflow001-qa.azurewebsites.net)では「Success Hello!!」の
文字が表示されるように設定しました。
■ 環境１
■環境２
この状態で、スワップを実行したいと思います。
操作は簡単です。
先ほどもアクセスした、デプロイ スロットの画面に遷移します。
その画面上にある、「スワップ」をクリックします。画面右に、スワップのソース、ターゲットなどを設定できる画面が表示されますので、その画面下にある、「スワップ」をクリックします。
これで、スワップ処理が実行されます。
スワップ処理の完了後、画面表示も入れ替わりました。
■環境１
■環境２
このように、簡単な操作でスワップ処理を実行することができました。
併せて、App Serviceのスロットのスワップについても、動作の確認を行いました。
引き続き、Azure DevOpsの機能を確認しながら、より本格的な環境を構築していきたいと思います。
QESでは様々なアプリケーションの開発・導入を行っております。
私共が提供するサービス・ソリューションにつきましてはこちらに掲載しております。
また、現在Power Platform に力を入れて取り組んでいます。Power Apps等のPower Platformについては、こちらをご覧ください。
システム開発・構築でお困りの問題や弊社が提供するサービス・ソリューションにご興味を抱かれましたら、是非一度お問い合せください。
ちなみにQESではクラウドエンジニアも募集していますので
QESの仕事内容や転職にご興味のある方はこちらもご覧ください。
このブログで参照されている、Microsoft、Windows、ASP.NET Core、Power Apps、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。
今回は、開発環境とは別の環境(例えば本番環境やQA環境)へリリースする際に承認を必要とするような承認アクションをパイプラインに実装してみます。
併せて、App Serviceでデプロイ スロットを実装し、スロットのスワップ機能も試してみます。
1. デプロイ スロットを追加する
前回の記事で掲載されている手順を元に、DevOps Starterで環境を構築します。プロジェクト名等は、以下のように設定しました。
次に、App Serviceでデプロイ スロットを利用できるプランに変更します。
アプリのApp Serviceプランが「S1」ではない場合は、「S1」に変更してください。（注）
変更手順は、以下のURL先にある「アプリを別の App Service プランに移動する」をご参照ください。
https://docs.microsoft.com/ja-jp/azure/app-service/app-service-plan-manage
（注）：デプロイ スロットを利用できるようにするためには、App ServiceのプランをStandard以上にする必要があります。課金が発生しますので、検証される際は注意してください！
プランの変更後、新ためてApp Serviceの画面に移動します。
左側メニューの「デプロイ スロット」をクリックします。
デプロイ スロットが追加されていない旨のメッセージが表示されていますね。
早速、デプロイ スロットの追加を行いましょう。
「スロットの追加」をクリックします。
「スロットの追加」が画面右側に表示されます。ここでは設定を引き継ぐことができます。
今回は以下のように設定してみます。
| 項目 | 値 | 備考 |
|---|---|---|
| 名前 | qa | |
| 次から設定を複製 | qesflow001 | 今回のDevOpsプロジェクト作成時に自動的に作成された Web App |
設定後、画面下の「追加」をクリックしてください。
これでデプロイ スロット「qesflow001-qa」が追加されます。
2. 承認アクションを追加する
さて、デプロイ スロットが追加されたので、ここからは承認アクションを設定します。今回は、「qesflow001」を開発環境、「qesflow001-qa」をQA環境と見立てて、フローを作成したいと思います。
まずは、「qesflow001」のAzure DevOps メイン画面を表示させましょう。
そのメイン画面で、「Pipelines」 - 「Releases」をクリックします。
クリック後、画面右側で、今回作成したプロジェクトを選択した状態で、
画面右上の「Edit」をクリックします。
Edit画面に移りました。
「Stages」配下の「dev」上にマウスカーソルを置くと、コピーのアイコンが表示されます。
このアイコンをクリックしてください。これで、既存のStageをクローンできます。
クローンが完了したら、クローンしたStageの名前を「QA」と変更しましょう。
次に、「QA」stageの設定を変更します。
「QA」stageの「1 job, 4 tasks」のリンクをクリックします。
その後、「Deploy Azure App Service」をクリックします。画面右側に細かい設定項目が表示されます。
この中にある、「Deploy to slot」のチェックボックスをクリックしてみましょう。
「Slot」には先ほど作成した「qa」を指定します。
最後に、画面上部の「Save」をクリックし、適宜コメントを書いてからOKをクリックします。
これで、本stageのデプロイ先が、デプロイ スロットである「qa」に設定されました。
一度、Releasesの動作を確認してみましょう。
前回の記事のように、「index.cshtml」ファイルを修正し、パイプラインを流してみます。
両方の環境とも、htmlファイルの変更が反映されていることが確認できました。
（今回、「Success！」を「Success Hello!!」に変更しました）
■開発環境(URLがhttps://qesflow001.azurewebsite.net)
■QA環境(URLがhttps://qesflow001-qa.azurewebsite.net)
リリースの追加も完了しましたので、次は承認アクションを追加します。
再度、プロジェクトのEdit画面に移りましょう。
そして、赤枠で囲ったアイコンをクリックしてください。
「QA」Stageが実行される前提条件を設定することができます。
ここで、承認者に指定した担当者がOKをしない限り「QA」Stageが実行されないように設定できます。
「Pre-deployment approvals」欄に、承認者を設定します。
今回は自分自身を設定してみましょう。
自分のAzureアカウントに設定しているメールアドレスを入力して、承認者を設定します。
設定できましたら、画面上部の「Save」をクリックします。
これで、「QA」Stage処理前に、承認者に指定された担当者が承認を行わないと「QA」Stageの処理が行われないようになりました。
以下のように、「QA」Stageの下に「Approve」というボタンがありますね。
このボタンをクリックすれば、「QA」Stageの処理が実行されるようになります。
では、「Approve」ボタンをクリックします。
すると、以下の画面が表示されます。
適宜、コメントを残し、「Approve」ボタンをクリックします。
ボタンクリック後、「QA」stageの処理が実行されます。
以下のような画面が表示されましたね。
これで、無事に承認作業が完了しました。
閉じるボタンをクリックして、この画面を閉じます。
以下のように、「QA」stageの処理が実行されています！
3. App Serviceのスロットのスワップ機能を確認する
さて、今回は同一アプリ内にある２つのデプロイ スロットそれぞれに対して、モジュールをリリースするように設定しています。しかし、実際の環境においては、同一アプリ内に、STG環境と本番環境があるとして、STG環境に修正モジュールをリリース、動作確認で問題がなければそのままスワップ処理を実行して、STG環境と本番環境を入れ替える、といった実装のほうが望ましいのではないでしょうか。
せっかくなので、最後にApp Serviceのスロット スワップの動作確認を行いたいと思います。
今回作成したApp Serviceには2スロット分の環境があります。
スワップ処理の実行結果がわかるように、
環境１(https://qesflow001.azurewebsites.net)では、「Success Hello Again!!!」と、環境2(https://qesflow001-qa.azurewebsites.net)では「Success Hello!!」の
文字が表示されるように設定しました。
■ 環境１
■環境２
この状態で、スワップを実行したいと思います。
操作は簡単です。
先ほどもアクセスした、デプロイ スロットの画面に遷移します。
その画面上にある、「スワップ」をクリックします。画面右に、スワップのソース、ターゲットなどを設定できる画面が表示されますので、その画面下にある、「スワップ」をクリックします。
これで、スワップ処理が実行されます。
スワップ処理の完了後、画面表示も入れ替わりました。
■環境１
■環境２
このように、簡単な操作でスワップ処理を実行することができました。
4. 最後に
今回は、Azure DevOpsでのリリース処理時に、承認が必要になる設定を行いました。併せて、App Serviceのスロットのスワップについても、動作の確認を行いました。
引き続き、Azure DevOpsの機能を確認しながら、より本格的な環境を構築していきたいと思います。
QESでは様々なアプリケーションの開発・導入を行っております。
私共が提供するサービス・ソリューションにつきましてはこちらに掲載しております。
また、現在Power Platform に力を入れて取り組んでいます。Power Apps等のPower Platformについては、こちらをご覧ください。
システム開発・構築でお困りの問題や弊社が提供するサービス・ソリューションにご興味を抱かれましたら、是非一度お問い合せください。
ちなみにQESではクラウドエンジニアも募集していますので
QESの仕事内容や転職にご興味のある方はこちらもご覧ください。
このブログで参照されている、Microsoft、Windows、ASP.NET Core、Power Apps、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。
