本記事は Azure DevOps Advent Calendar 2020 - Qiita 14 日目の投稿です。
- はじめに
- やりたいこと
- 全体の動作イメージ
- Environment の作成と VM の登録
- アプリケーションの作成
- パイプラインの作成
- 本番環境への配置前に承認処理を入れる
- 動作確認
- もっと使い込む
- まとめ
はじめに
Azure Pipelines で VM や k8s 環境にアプリケーションを配置するには Environments という機能を活用します。 これについては既に以下の記事で解説しました。
今回は、エンプラ系のしっかりとした開発プロセスでも、こういった機能を活用できるようにするリリース前承認の機能を解説します。
やりたいこと
開発/テスト環境、本番環境に対して、自動デプロイを行います。 開発/テスト環境には、特に承認の作業なくアプリケーションをデプロイできるようにします。 本番環境へのデプロイは、開発/テスト環境での動作を確認できた後に、人の承認があって、デプロイするようにします。
全体の動作イメージ
以下のような動作を実現できるようにしていきます。
なおこの前段には、アプリケーションをパッケージングし、アーティファクトとして Azure DevOps にアップロードしていることを前提にします。
① 開発/テスト環境のエージェントが、自分の環境にダウンロードするべきアーティファクトがないか、ポーリングします（エージェントが自動でやってくれます）
② ダウンロードするべきアーティファクトを検知すると、それを開発/テスト環境にダウンロードします
③ ダウンロードしたパッケージを自サーバー内に展開して配置し、開発/テスト環境を更新します
④ Azure DevOps から、本番環境に配置しても良いか、レビューを依頼するメールが事前に登録したレビュアーに届きます
⑤ レビュアーは開発環境上で動作確認を行い、リリース可能かどうかを判定します
⑥ レビュアーは Azure Pipelines 上でレビュー結果を記録します（OK か NG かの 2 択）
⑦ 本番環境のエージェントが、自分の環境にダウンロードするべきアーティファクトがないか、ポーリングします（レビューが通ったもののみが対象になります）
⑧ ダウンロードするべきアーティファクトを検知すると、それを本番環境にダウンロードします
⑨ ダウンロードしたパッケージを自サーバー内に展開して配置し、本番環境を更新します
Environment の作成と VM の登録
今回は開発/テスト環境をあらわす「Development」と、本番環境を表す「Production」の 2 つの Environment を作成します。
それぞれの Environment には、 VM を 1 台ずつ登録しています。
Environment の作成や VM の登録については以下の記事で詳細に解説していますのでそちらをご覧ください。
アプリケーションの作成
今回は .NET 5 のアプリケーションを適当に作成して使用します。 ソリューション名、プロジェクト名、フォルダ構造などは以下をご覧ください。
パイプラインの作成
続いてパイプラインの YAML を作成していきます。 以下に作成した YAML を公開してあります。
やることは非常にシンプルで、アプリケーションのパッケージングを行い、各 Environment に配置するだけです。 パッケージングと配置はそれぞれ別の Stage として作成しています。 配置の Stage は、それぞれ前段の Stage の処理が正常に完了しなければ動作しないように設定しています。
本番環境への配置前に承認処理を入れる
ここまでの状態でパイプラインを実行すると、アプリケーションのパッケージング、開発/テスト環境への配置、本番環境への配置が順次実行されます。
ここから、本番環境への配置前に人手の承認処理が行えるよう設定を行っていきます。
[Pipelines] → [Environments] メニューを選択して、承認処理を行いたい Environment を選択します。 今回は本番環境へのリリース前に承認処理を挟み込むので、 Production を選択します。 そして右上の三点リーダーを押下し、 [Approvals and checks] を選択します。
[Approvals and checks] の画面の右上にある [+] ボタンを押下します。
すると、この Environment にリリースするための条件を選択・設定することができます。 今回は人手の承認処理を行いたいので [Approvals] を選択します。
承認者を [Approvers] に設定します。 承認者は Azure DevOps に対して登録したユーザーを個別に指定することもできますし、チームやグループを指定することもできます。
以上で設定は完了です。
動作確認
再度作成しておいたパイプラインを実行してみましょう。 アプリケーションのパッケージング、開発/テスト環境へのリリースは、今まで同様、自動的に流れていきます。 しかし、本番環境へのリリースを行う前にパイプラインの実行が停止します。 そして、レビューを促すボタンが表示されます。
先ほど設定したレビュアーのもとには、承認依頼がメールで飛びます（ただしこのメールは英語です）。
レビュアーは、開発/テスト環境にリリースされているアプリケーションを確認したり、各種メトリクスを参照したりして、本番環境への配置が可能な品質かを確認します。 問題がなければ、 [Approve] ボタンを押下します。
すると、今まで止まっていた処理が流れ始めます。
これで、本番環境へのリリース前に、人手の承認処理を挟み込むことができました。
なお承認処理にはタイムアウト時間を設定することもできるので、無駄に Waiting 状態で放置され続ける心配も少なくなります。 タイムアウトした場合は、処理自体が Skip され、以下のように記録が残ります。
もっと使い込む
Environment にリリースするための条件確認には、今回紹介した人手の承認処理以外にも様々なものがあります。 その中から特に有用なものをご紹介します。
Git リポジトリのブランチ運用ルールが明確になっているような開発では、 [Branch control] を活用するのが良いと思います。 本番環境には [main] ブランチからビルドしたモジュールしか配置できない、といったルールを簡単に作成することができます。 誤ってテスト用のモジュールを本番環境に配置してしまった、というミスも防げます。 このチェック機能はほとんど害悪がないので、是非使っていただきたいです。
またエンタープライズ系のシステムですと、業務の行われていない夜間にリリースしたいケースもあると思います。 今までだと人が張り付いてリリースの行く末を見守っていたと思いますが、 [Business Hours] を使えばそういった問題が解決できるかもしれません（相当難しいと思いますが。。。）。
もっと柔軟にいろいろ確認したいのであれば、 [Invoke Azure Function] も有用です。 例えば開発環境に対する一通りの動作確認を Azure Function で作成しておき、その処理を実行するように構成できれば、人手による確認を、より軽量化できるはずです。
まとめ
今回は Environment へのリリースチェック機能を紹介しました。 今回は VM を用いた例を提示しましたが、 Environment は k8s にも対応していますので、幅広く活用できるのではないでしょうか。 より安全に、より手間をかけず、リリースできるための仕組みを作っていきたいですね。
