如何从Git仓库部署部署槽专属AppSettings并实现版本管控？

我来帮你梳理下这两个问题的解决方案，都是实际项目里踩过坑后总结的实用思路：

不想手动在Portal加配置，同时要做版本管控，有几个主流方案：

• 用ARM模板/Bicep定义槽位配置
  把Web App和部署槽的所有应用设置、连接字符串都写进ARM模板或者Bicep文件里，和你的代码一起提交到Git仓库。部署的时候，用Azure DevOps或者GitHub Actions的模板部署任务来更新槽位配置。
  比如在Bicep里，给部署槽定义粘性设置的写法：

  resource stagingSlot 'Microsoft.Web/sites/slots@2023-01-01' = {
    name: '${webAppName}/staging'
    properties: {
      siteConfig: {
        appSettings: [
          {
            name: 'StagingOnlySetting'
            value: 'staging-value'
            slotStickySetting: true // 标记为槽粘性设置，不会随交换变动
          }
        ]
        connectionStrings: [
          // 同理配置连接字符串的粘性属性
        ]
      }
    }
  }
  

  这样每次配置变更都要提交模板，天然实现版本管控，还能和代码部署同步。

• 用Azure DevOps变量组管理配置
  把不同槽位的专属配置存在Azure DevOps的变量组里（比如StagingSettings和ProdSettings），变量组可以设置权限，还能和Git仓库关联做变更记录。
  在发布管道的Azure App Service部署任务里，勾选“使用来自发布管道的应用设置”，然后把变量组里的变量映射到应用设置。这样每次修改配置只需要更新变量组，发布时自动同步到对应槽位，全程不用碰Portal。

• 用Azure App Configuration做集中配置管理
  这是专门的配置服务，支持和Git集成、版本回溯、槽位标签区分。你可以给staging和prod的配置分别打标签，然后在应用里根据当前运行的槽位，自动读取对应标签的配置。
  这种方式把配置和代码完全分离，变更配置不用改代码，还能通过Git或者App Configuration本身的版本记录追踪所有配置变更。

先给你理清槽位交换的核心逻辑：非粘性设置会在交换前被目标槽的配置覆盖，粘性设置会留在原槽位。你遇到的问题，大概率是因为给staging加的新设置没标记为粘性，交换时被prod槽的原有配置覆盖了。

解决办法分两种场景：

如果这个设置是staging槽专属的（prod不需要） #

把这个设置标记为槽粘性设置：

• 在Azure App Service部署任务里，添加应用设置时，在设置项里加上"slotStickySetting": true；
• 或者用上面说的ARM/Bicep模板定义时，给该设置加上这个属性。
  这样交换槽位时，这个设置会牢牢留在staging槽里，不会被prod的配置覆盖，交换后prod槽也不会拿到这个设置（符合你的槽专属需求）。

如果这个设置是每个槽都需要，只是值不同 #

• 提前在发布管道里给所有槽位（staging和prod）都配置好对应的值，比如用不同的变量组分别部署到staging和prod；
• 或者用Azure App Configuration的标签功能，每个槽读取自己标签下的配置，不管怎么交换，应用都会自动加载当前槽的配置，完全不用担心交换时的配置丢失问题。

另外要注意：如果是在发布任务里临时添加的设置，一定要确认是否勾选了“槽粘性”选项，否则交换时很容易被覆盖。

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