Azure项目Kudu接收ZipDeploy上传的Zip包但未完成部署求助

我之前把ASP.NET Core项目从VS手动发布迁移到CI/CD工具时，也碰到过一模一样的Kudu接收了Zip包但部署卡住的问题，给你几个亲测有效的排查和解决方向：

1. 先确认Zip包的结构是否正确 #

这是最常见的坑！Kudu要求Zip包的根目录必须直接包含网站核心文件（比如web.config、bin文件夹、wwwroot等），而不是把这些文件嵌套在项目名称的子文件夹里。

• 把Bamboo生成的Zip包本地解压，对比VS2017发布时生成的包结构，看看是不是多了一层嵌套。
• 在Bamboo的打包任务里，一定要配置成打包发布输出目录的内容，而不是整个项目源码目录。

2. 查看Kudu的详细部署日志找原因 #

Azure提供了非常详细的日志，别盲目试错，先定位问题：

• 登录Azure门户，进入你的QA部署槽，找到「部署中心」->「日志」，或者直接访问Kudu的部署记录页面查看细节。
• 日志里会明确标注部署失败的具体原因，比如“找不到web.config”“依赖项缺失”“文件被占用”等，针对性解决即可。

3. 检查Bamboo的ZipDeploy请求参数是否合规 #

Kudu对ZipDeploy的请求格式有严格要求，CI工具很容易在这里出错：

• 确认请求地址正确：https://<部署用户名>:<部署密码>@<你的应用名>-qa.scm.azurewebsites.net/api/zipdeploy
• 确保请求头的Content-Type设置为application/zip，并且Zip包是作为请求体直接上传的，不要用multipart/form-data格式。
• 可以先用Postman手动模拟一次ZipDeploy，如果手动能成功，那肯定是Bamboo的请求配置有问题，对比参数调整即可。

4. 核对部署槽的配置设置 #

有些槽的配置会影响部署行为：

• 检查QA槽的「部署设置」里，部署方式是不是「自动」，如果是「手动」的话，需要手动触发部署完成（VS发布时会自动处理这一步）。
• 查看应用设置里的WEBSITE_RUN_FROM_PACKAGE，如果这个值设为1，App Service会直接从Zip包运行，此时部署逻辑和常规ZipDeploy不同，要确保这个设置和之前VS发布时一致。

5. 清理Kudu的临时文件 #

有时候Kudu临时目录残留的旧文件会导致部署卡住：

• 访问Kudu控制台（https://<你的应用名>-qa.scm.azurewebsites.net/DebugConsole），删除D:\home\site\deployments\tmp下的所有文件，然后重新发起Bamboo部署试试。

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