Azure App Service交换生产槽后无法重新部署至预发布槽求助

问题核心 #

你的问题本质是Azure App Service默认的GitHub部署连接绑定在实例而非部署槽上，交换staging和production槽时，底层实例的部署配置会随之转移，导致原生产实例（转为staging槽后）的GitHub连接仍指向生产环境配置，进而无法正常部署。

可行解决方案 #

1. 为每个部署槽单独配置独立GitHub部署源 #

不要使用应用级全局部署设置，进入每个槽的部署中心单独配置GitHub连接：

• 打开Azure门户，进入目标App Service，切换至staging槽
• 进入“部署中心”，选择GitHub作为源，重新完成授权与仓库绑定
• 切换至production槽，重复上述操作绑定同一仓库，确保每个槽的部署配置是独立的
  此方式下，每个槽的部署凭据绑定到槽本身，交换槽时不会随实例转移。

2. 使用GitHub Actions直接部署到指定槽（推荐） #

放弃App Service自带的部署绑定，改用GitHub Actions工作流控制部署目标，彻底避开实例绑定问题：

• 在GitHub仓库的.github/workflows目录下创建部署脚本（如deploy-to-staging.yml）
• 使用Azure官方部署动作azure/webapps-deploy@v2，明确指定部署槽名：

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: azure/login@v2
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
      - uses: azure/webapps-deploy@v2
        with:
          app-name: <你的App Service名称>
          slot-name: staging  # 指定部署到staging槽
          package: .

这种方式的部署目标是槽的逻辑名称，与底层运行实例无关，交换槽后仍可正常部署到staging槽。

3. 确认槽的配置独立性 #

检查槽的配置是否开启独立性：

• 在槽的“配置”页面，确认“部署中心”相关设置未标记为“继承生产槽配置”，确保每个槽的部署设置是独立的
• 若之前为继承配置，改为独立配置后重新绑定GitHub。

补充说明 #

你遇到的是Azure App Service早期部署机制的常见问题，默认部署绑定与实例关联而非槽的逻辑标识。上述两种方法（独立槽部署配置或GitHub Actions）均可彻底解决问题，其中GitHub Actions更灵活，符合现代CI/CD最佳实践。

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