Azure DevOps .NET项目CI/CD管道Zip部署CD环节失败如何解决

以下是这类问题的高频根因和对应排查步骤，按出现概率从高到低排序：

• 先核对部署包的结构正确性
  这是新手最容易踩的坑：CI环节虽然生成了zip包，但包的目录结构不符合Zip部署要求。你可以直接从CI产物里下载生成的zip包本地解压检查：正确的部署包解压后根目录应该直接放项目编译生成的主dll、runtimeconfig.json、web.config（IIS托管场景）这类启动文件，要是解压后先看到一层嵌套的项目文件夹、或者bin/Release/netx.x/publish这类多层目录，部署时Azure找不到入口文件会直接失败。
  这类问题的修复方式很简单：要么修改CI里dotnet publish步骤的输出路径，直接把publish生成的所有文件打zip，不要套外层目录；要么调整CD部署任务里的包匹配规则，不要误把源码压缩包、非publish输出的zip当成部署包。
• 校验服务连接的权限有效性
  CD环节用的Azure Resource Manager服务连接权限不足是第二高频原因：很多人配置服务连接时选的服务主体只有资源读取权限，没有App Service的写入、部署权限，能在管道里选到对应的App Service，但实际执行部署上传操作时会被权限拦截。
  排查时直接去DevOps项目设置-服务连接页，找到你CD用的那个Azure连接，点验证按钮做连通性和权限校验，如果验证失败，要么用有订阅参与者权限的账号重新授权服务连接，要么手动给服务关联的服务主体授予目标App Service的部署权限。
• 核对部署任务的参数配置
  如果你用官方的Azure App Service deploy任务做部署，重点核对几个参数：
  1. 部署类型明确选Zip Deploy，不要和Web Deploy模式混用
  2. Zip部署模式下要关掉使用Web Deploy发布的勾选，开这个选项会触发不兼容的校验逻辑直接报错
  3. 项目目标.NET版本要和任务里选的runtime版本匹配，不要留默认的空值
  4. 打开任务的详细日志开关，不要只看报错摘要，完整日志里会直接返回Azure侧的具体错误原因
• 排查App Service侧的配置冲突
  1. 先去Azure门户对应App Service的部署中心，关掉其他自动部署源（比如Git自动部署、FTP自动同步），多部署源同时开的时候会出现站点文件锁，部署时文件写入失败。建议直接在应用设置里加WEBSITE_RUN_FROM_PACKAGE=1，这是官方推荐的Zip部署配置，开启后App Service会直接挂载zip包运行，不会解压文件到站点目录，能彻底规避文件锁问题。
  2. 核对App Service的运行时栈配置和项目目标框架一致：比如项目是.NET 8，服务栈选成.NET 6的话，就算包上传成功也会启动失败，管道会报部署后应用不可用的错误。
  3. 要是报403、502类的网络错误，先去门户点高级工具进Kudu站点，确认SCM部署服务正常运行，如果Kudu打不开，先重启App Service再重试部署。
• 快速定位问题的技巧
  别盯着CD任务最开头的通用报错看，点进失败任务拉取完整日志，搜索error、Failed to deploy、SCM相关的日志行，90%的场景下日志会直接写明失败原因。如果日志提示包上传成功但应用启动失败，直接去App Service的诊断页查启动日志，这类问题一般是项目缺配置、缺依赖导致的，和部署流程本身无关。

要是按以上步骤排查完还是无法解决，可以把CD任务里脱敏后的完整错误日志贴出来，能进一步定位具体问题。

内容的提问来源于stack exchange，提问作者Saikumar