Azure DevOps中为Azure App Service使用槽位部署的方法及部署期间应用宕机问题求助

看起来你遇到的是槽位部署流程中意外触发生产环境重启的问题——哪怕资源组已经存在、ARM模板没有变更，还是在资源组部署阶段就出现了宕机。我来帮你拆解可能的原因和对应的解决办法：

1. 先确认部署任务的目标是不是错指向了生产槽 #

很多时候这个问题的根源是部署任务没选对目标：

• 如果你用的是Azure App Service Deploy任务：一定要在「Deployment Slot」选项里选择你手动创建的那个部署槽，而不是默认的生产槽。直接部署到生产槽肯定会导致重启，槽位部署的核心就是先把代码/配置推到槽位，验证后再交换到生产。
• 如果你用的是ARM部署任务（Azure Deployment: Create Or Update Resource Group）：你的azuredeploy.json可能只定义了生产槽的Web App资源，哪怕你手动建了部署槽，这个任务还是会去检查并更新生产槽的配置。这种情况下，要么修改模板添加部署槽的资源定义，要么拆分流程，用专门的App Service部署任务处理槽位部署。

2. 检查ARM模板里触发重启的配置项 #

增量模式下，ARM会对比模板和现有资源的所有属性，哪怕是细微的差异都可能触发生产槽重启。重点排查这些容易踩坑的配置：

• 应用设置（appSettings）：哪怕值完全一样，模板里的键值对顺序、格式（比如多余的空格、引号）都可能让ARM认为需要更新。建议把应用设置改成参数化传递，或者在模板里给appsettings资源添加ignoreChanges属性，跳过对这些配置的检查：

  {
    "type": "Microsoft.Web/sites/config",
    "apiVersion": "2022-09-01",
    "name": "[concat(parameters('webAppName'), '/appsettings')]",
    "dependsOn": ["[resourceId('Microsoft.Web/sites', parameters('webAppName'))]"],
    "properties": "[parameters('appSettings')]",
    "metadata": {
      "ignoreChanges": ["*"]
    }
  }
  

• 连接字符串、运行时版本：connectionStrings、linuxFxVersion（或windowsFxVersion）这些属性的任何变更都会强制重启应用。如果这些配置在生产环境已经稳定，同样可以用ignoreChanges来跳过检查。

3. 拆分部署流程，避免不必要的资源组更新 #

既然你的资源组已经存在且无需变更，完全可以把部署拆成两部分：

• 第一部分：用ARM部署只处理基础资源（比如App Service计划、存储账户等），这部分只在资源变更时运行。
• 第二部分：用Azure App Service Deploy任务专门部署代码到槽位，这个任务不会触及资源组层面的配置，只会更新槽位的代码和应用设置，避免影响生产槽。

4. 查看部署日志定位具体原因 #

最后，一定要去Azure DevOps里看Azure Deployment: Create Or Update Resource Group任务的详细日志，找有没有「Updating resource...」的条目——这就是触发重启的具体资源。比如如果日志显示正在更新Web App的siteConfig，那就能精准定位到是哪个配置项引发的问题。

按照这些步骤排查下来，应该能解决你的宕机问题。如果还有细节搞不定，把日志里的关键片段贴出来，我再帮你分析。

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