Azure Pipelines の「Failed to deploy web package to App Service」：後ろのコードが意味すること
App Service のデプロイのタスク（AzureRmWebAppDeployment@4 と @5、AzureWebApp@1、Azure Functions のデプロイのタスク）は、パッケージをアプリのデプロイのサービス Kudu に、scm のサイト（https://<app>.scm.azurewebsites.net）経由でアップロードします。アップロードが失敗すると、タスクはこの文を書き、返ってきたものを後ろに足します。scm のサイトの HTTP の状態（Conflict (CODE: 409) の形）か、エージェントがサイトに届かなかったときのネットワークのエラーです。文そのものはどの原因でも同じなので、手がかりは後ろの部分です（このメッセージについての Stack Overflow の質問は4万4千回以上見られています）。
デプロイがプルリクエストのビルド検証で動いていると、デプロイが通るまで必須のビルドは失敗のままです：JetBrains IDE のプラグイン Azure DevOps Pull Requests は、そのプルリクエストのブランチ ポリシーを状態つきで IDE に並べ、Pro ならパイプラインを直したあとで失敗したビルド ポリシーをそこからもう一度動かせます。JetBrains Marketplace で入れる
どう見えるか
##[error]Error: Failed to deploy web package to App Service. Conflict (CODE: 409)。ほかの終わり方：Internal Server Error (CODE: 500)、Bad Request (CODE: 400)、Ip Forbidden (CODE: 403)、getaddrinfo ENOTFOUND <app>.scm.azurewebsites.net、connect ETIMEDOUT。- タスクのライブラリは、応答から
<状態の文> (CODE: <番号>)の形で後ろの部分を作ります。scm のサイトが返した理由は応答の本文にあり、表示はされません。変数system.debugをtrueにしてもう一度動かすと、ZIP Deploy の応答の全体がログに出ます。
Conflict (CODE: 409)
- Kudu のソース（Windows の App Service 向けの版）は、zip のデプロイに3つの場合で 409 を返します。別のデプロイがもう動いている、自動スワップの途中、またはアプリがリモートの URL のパッケージから動く設定になっている場合です。最後の場合、Kudu はその設定ではデプロイできないと答えます。
- 最初の2つなら、待ってからもう一度動かします。2つのステージやパイプラインが、同じアプリやスロットに同時にデプロイしないようにします。3つ目なら、アプリの設定からリモートのパッケージの URL を外すか、その URL を変えてデプロイします。
- いちばん読まれている 409 の質問では、App Service プランが Free の枠の上限に達していたことを Microsoft のサポートが見つけ、有料の枠に上げて直りました（採用された回答）。いちばん票の多い回答は、アプリの再起動で直しています。
Internal Server Error (CODE: 500) か Bad Request (CODE: 400)
- これはアプリの側を指しています。いちばん読まれている 500 の質問では、前にアプリのデプロイ センターで設定したソース管理の接続が原因でした。接続を外したあとも Kudu に
deploymentsのフォルダーが残っていてデプロイを壊しており、そのフォルダーを消して直りました（採用された回答）。上の最初の質問では、デプロイ センターで Disconnect を選んで直した回答があります。 - ディスクがいっぱいでも同じ結果になります。アプリの高度なツール（Kudu）を開いて、ディスクの使用量を見ます。容量が尽きたことを挙げる回答もあります（400 の質問）。
Ip Forbidden (CODE: 403)・ENOTFOUND・ETIMEDOUT：エージェントが scm のサイトに届かない
- プライベート エンドポイントを付けるとアプリはインターネットから切り離され、Microsoft ホストのエージェントは公開のアドレスからつなぎます。プライベート エンドポイントに届く仮想ネットワークの中の、セルフホストのエージェント（VM かスケール セット）でデプロイを動かします（403 の質問で採用された回答）。
- アクセス制限は scm のサイトにもかかります。scm のサイトには高度なツールのサイトという別の一覧があり、メインのサイトの規則を使うこともできます（アクセス制限についての Microsoft のページ）。メインのサイトを絞ったなら、デプロイするエージェントを scm のサイトで許可する必要があります。
getaddrinfo ENOTFOUNDは、エージェントが<app>.scm.azurewebsites.netを引けなかったという意味です。プライベート エンドポイントがあるなら、エージェントはプライベート DNS ゾーンを使える必要があります。クラシックのリリースなら Run on agent も確かめます。ある質問では新しいリリースのエージェント プールが変わっていて、正しいプールを選んで直りました。
Web Deploy の ERROR_FILE_IN_USE
- Deployment method が Web Deploy だと、失敗の見え方が違います。動いているアプリがつかんでいるファイルを、Web Deploy が置き換えられません。Rename locked files と Take App Offline は既定でオンですが、いつも効くわけではありません。Microsoft のサポートは、名前の変更は DLL にしか効かないと質問者に伝え、Additional arguments の
-useChecksumで直りました（採用された回答）。 - タスク自身は、これに Run From Package を勧めています。アプリは zip から動くので、その場でファイルを置き換えません。MSBuild のパッケージは受け付けません。
IntelliJ IDEA と Rider で Azure DevOps のプルリクエスト
Azure DevOps Pull Requests は、Lesstep が作っている JetBrains IDE（2024.1 以降）と Android Studio のプラグインです。組織・プロジェクト・リポジトリを git のリモートから読み、自分のレビューを待っているプルリクエストを IDE のツールウィンドウに並べます。Azure DevOps Services でも Azure DevOps Server でも使えます。プルリクエストのブランチ ポリシーを状態つきで並べるので、まだ通っていない必須のビルドがそのプルリクエストの横に出て、Pro なら失敗したか期限が切れたビルド ポリシーをそこからもう一度動かせます。レビューの受信箱は無料、投票・コメント・完了・作成は Pro（30日間の無料試用つき）です。画面は日本語です。
Azure DevOps・Azure Pipelines・Azure App Service は Microsoft Corporation の商標、GitHub は GitHub, Inc. の商標、IntelliJ IDEA・Rider は JetBrains s.r.o. の商標です。このページは Microsoft・GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：dotnet のタスクがプロジェクトを見つけられない · デプロイのタスクが探すところに zip がない · テンプレートか、パラメーター ファイルがない · リソースの承認の問題 · English