アプリケーション開発では開発環境、ステージング環境、本番環境など複数の環境を用意します。
Azure DevOpsでCI/CDを行う場合もデプロイ先を切り分けたいので簡単な方法を検討してみます。

ベースとなる環境（今回は本番環境と仮定）の作成は以下記事を参照してください。
今回は本番に加えてステージング環境を作って、Reposのstagingブランチにコミットがあった際にステージング環境にデプロイされるようにします。

WebApp for Containerを作成する（ステージング用）

本番と同じなので割愛します。

Reposでブランチを作成

Releasesを作成

新しくReleasesを作成し、トリガーのBuild Branch filtersに作成したstagingブランチを設定

Stageは本番ではないのでWebAppのデプロイスロットは使わず直接運用スロットへデプロイし、再起動をしています
デプロイ先はもちろん新規で作成したWebAppを指定します

ACRは本番環境と共有（実際には分けたほうが良いかもしれない）するので、タグとして分かりやすいように$(Build.SourceBranchName)でブランチ名を付与しています
タグを一意にする方法については以下記事参照

stagingブランチでyamlファイルを修正

トリガーにstagingを追加

trigger:
  - master
  - staging

コンテナタグにブランチ名を付与

  - task: Docker@2
    displayName: Build and push an image to container registry
    inputs:
      command: buildAndPush
      repository: $(imageRepository)
      dockerfile: $(dockerfilePath)
      containerRegistry: $(dockerRegistryServiceConnection)
      tags: |
        $(tag)-$(Build.SourceBranchName)

変更をコミットし、新しいReleasesがトリガーされ、WebAppが更新されればOK
stagingで問題なければmainにプルリクエストを出し、マージすれば本番のPipelineがトリガーされる

以上