Azure App Service部署槽与KeyVault在ADO发布管道中的配置问询

基于你的需求（通过ADO经典版发布管道实现零停机部署，且两个槽分别使用不同KeyVault中的连接字符串，全程不依赖Azure Portal），推荐以下落地方案：

核心思路 #

利用Azure App Service的**槽位专属设置（Deployment Slot Setting）**特性，给Staging和生产槽分别配置独立的KeyVault连接字符串引用，确保槽交换时不会覆盖彼此的配置，同时所有配置操作都通过ADO管道完成。

具体实施步骤 #

1. 准备双KeyVault及权限配置 #

• 分别创建Staging环境专用KeyVault（存储ConnectionStringA）和生产环境专用KeyVault（存储ConnectionStringB）
• 为你的Azure App Service的系统托管身份分配两个KeyVault的Secret Get权限（确保两个槽都能访问对应的密钥）

2. 改造ADO经典发布管道 #

阶段1：部署Staging槽时配置专属KeyVault引用

在现有Staging部署阶段中，添加「Azure App Service 设置」任务：

• 目标槽选择Staging
• 添加连接字符串项：键名设为统一名称（比如DBConnection），值填入Staging KeyVault的密钥引用格式：

  @Microsoft.KeyVault(SecretUri=https://<你的Staging KeyVault名称>.vault.azure.net/secrets/ConnectionStringA/)
  

• 勾选该设置的Deployment Slot Setting选项（关键：标记为槽专属，交换时不会被同步）

阶段2：槽交换前配置生产槽的专属KeyVault引用

在槽交换任务之前，添加「Azure App Service 设置」任务：

• 目标槽选择Production
• 添加同键名的连接字符串项，值填入生产KeyVault的密钥引用格式：

  @Microsoft.KeyVault(SecretUri=https://<你的生产KeyVault名称>.vault.azure.net/secrets/ConnectionStringB/)
  

• 同样勾选Deployment Slot Setting选项

阶段3：保留原有槽交换及回滚逻辑

继续执行原有的槽交换任务，此时：

• Staging槽始终使用自身KeyVault中的ConnectionStringA
• 生产槽始终使用自身KeyVault中的ConnectionStringB
• 槽交换后，原Staging的代码会自动加载生产槽的专属连接字符串，实现零停机部署；回滚时同理，不会影响配置隔离

3. 可选优化：变量组复用配置 #

在ADO中创建变量组，分别存储Staging和生产KeyVault的密钥URI，然后在「Azure App Service 设置」任务中引用变量，减少重复配置工作量。

方案优势 #

• 完全通过ADO管道完成配置，无需手动操作Azure Portal
• 两个环境的连接字符串都集中存储在KeyVault中，符合安全管理规范
• 槽专属设置确保配置隔离，槽交换时不会出现配置混乱问题

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