前提

私が勤務している会社ではお客様社内で利用するWebアプリを受注開発を行っています。
このときのAzure契約はお客様が行い、アカウントを作成してもらい開発者が利用します。
DevOpsを使ってテストおよびリリースを自動化する第１段のプロジェクトで、すべてが手作ぐり状態。

目的

Azure DevOpsにてMasterブランチにPushを検知し、ビルド＆テストそして、検証サーバにデプロイを行う。
検証サーバで検証できた後に、お客様のリリース担当者が意思入れのもと本番サーバにデプロイを行う。

プロジェクト作成

今回は.NetCoreをWeb Apps for Containerで運用します。
まずはAzure DevOpsプロジェクトの作成ですね。
追加をクリック

.Netを選択（お好きなアプリケーションを選んでください）

ASPNET Coreを選択

Web App for Containerを選択

その後、プロジェクト名やらはお好みを入れてください。
これで初期のプロジェクトが出来上がりますので、早速Azure ReposからソースをCloneします。

パイプラインの変更

プロジェクト作成当初のパイプライン(Release)はこんな感じになっています。
Stagesにdevが一つあります。今回はdevの他に本番リリースを追加します。

Web Apps for Containerの作成

まずは本番リリース用のWeb Apps for Containerを新たに作成します(ここではApprovalTestReleaseとする）

Releaseパイプラインに本番リリースを追加

ReleaseパイプラインのEditを選択

devStageの後に本番リリースStageを追加します。
やることはdevStageと同じでデプロイ先を変更するだけなのでdevStageをCloneしましょう。

Cloneすると"Copy of dev"が追加されます。
ここで、Copy of Devを編集していきましょう。

デプロイ先を変更

ステージ名を"本番リリース"に変更後
Deploy Azure App Serviceにある"App Service Name"を先程作ったApprovalTestReleaseに変更します。

承認を追加

パイプライン(Release)のPre-deployment approvalsをEnabledにし
Approvaersに承認する人を入力します。

確認

Cloneしたソースを変更しMasterブランチにPushします。
Buildパイプラインが走り、続いていReleaseパイプラインが走ります。

先程作成した本番リリースのパイプラインが追加されています。

あと、本番リリースを選択し"Approve"で本番サーバにリリースが行われます。
検証し、不具合がある場合は再度MasterブランチのPushを行いましょう。

このApproveボタンがあることにより不用意にMasterブランチをPushしても本番サーバに適用されませんし、リリース担当者が
検証を行うので（今回はお客さん）、安心して開発を進められますね。

なかなかDevOpsの日本語の資料が少なく、承認を入れるだけで苦労しましたが、分かってしまえば簡単ですね。