GitLab CI/CD部署Azure WebApp显示成功(Active)但应用未更新

针对你遇到的GitLab CI/CD部署Azure WebApp后代码未更新、新实例仅显示默认页面的问题，以下是具体排查方向和解决办法：

1. 构建与WAR包上传环节异常 #

• 核心原因：GitLab流水线可能未正确生成WAR包，或部署任务未将WAR包上传到Azure WebApp的正确目录。
• 排查步骤：
  • 查看GitLab构建日志，确认Maven/Gradle的打包命令（如mvn clean package）是否输出BUILD SUCCESS，且生成的WAR包路径正确。
  • 通过Azure门户的高级工具(Kudu) 进入site\wwwroot\webapps目录，检查是否存在最新的WAR包或解压后的应用文件夹。若该目录为空或只有旧文件，说明上传环节出问题。
• 解决办法：
  • 确保流水线中构建步骤完整执行，清理旧构建产物（如添加mvn clean）。
  • 部署时使用Azure CLI命令明确指定WAR包路径和类型：

    az webapp deploy --name <你的WebApp名称> --resource-group <资源组名称> --path ./target/your-app.war --type war
    

2. 部署后未触发应用重启 #

• 核心原因：Windows版WebApp在F1免费SKU下，可能因资源限制未自动重启应用池，导致旧代码持续运行。
• 排查步骤：手动在Azure门户重启WebApp，若重启后新代码生效，说明是自动重启未触发。
• 解决办法：在GitLab CI/CD的部署步骤后添加重启命令：

  az webapp restart --name <你的WebApp名称> --resource-group <资源组名称>
  

  或直接在az webapp deploy命令中加入--restart参数，强制部署后重启。

3. 部署目标路径错误 #

• 核心原因：部署任务可能将文件传到了临时目录或非站点根目录，而非site\wwwroot。
• 排查步骤：通过Kudu查看site目录下的其他文件夹（如deployments），确认WAR包是否被传到错误位置。
• 解决办法：部署时明确指定目标路径为站点根目录的webapps文件夹，或使用--type war参数让Azure自动处理部署路径。

4. F1 SKU资源限制导致部署未完成（虚假成功状态） #

• 核心原因：F1实例CPU、内存有限，WAR包解压或应用启动过程中因资源不足失败，但Azure部署日志仍标记为成功。
• 排查步骤：
  • 查看Azure门户的日志流(Log Stream)，检查是否有Java进程启动失败、内存溢出等报错。
  • 查看Kudu的LogFiles\Application目录下的日志文件，定位启动异常信息。
• 解决办法：
  • 临时升级到B1 SKU测试部署是否正常，若正常则说明F1资源不足。
  • 优化WAR包大小（移除无用依赖），调整JVM启动参数（如减小堆内存：-Xmx256m）以适配F1的资源限制。

5. 部署凭据或目标实例配置错误 #

• 核心原因：部署WAR包的任务可能使用了错误的Azure凭据，或指向了错误的WebApp实例（虽然Ansible能修改环境变量，但部署环节可能配置独立）。
• 排查步骤：检查GitLab CI/CD中部署任务的Azure订阅ID、资源组名称、WebApp名称是否与目标实例一致，确认服务主体拥有Web App Contributor权限。
• 解决办法：修正部署任务中的参数配置，确保凭据权限足够完成文件上传和应用重启操作。

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