Microsoft Teams应用后端服务版本管理：如何无影响提交新版本至Teams应用商店并区分多版本请求

我之前帮客户处理过类似的Teams应用版本迭代与蓝绿部署需求，结合Azure Bot Service和Teams应用商店的特性，分享几个针对性的解决方案：

一、Bot请求的版本区分核心方案 #

针对Bot通信无法区分版本的痛点，有两种可靠的实现方式：

1. 通过Teams应用Manifest传递版本标识 #

在Teams应用的manifest.json中添加自定义扩展属性，把版本号嵌入其中，这样Bot就能从收到的请求里提取版本信息，路由到对应环境：

{
  "$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.16/MicrosoftTeams.schema.json",
  "version": "2.0.0", // 正式版本号升级
  "extensions": {
    "customProperties": {
      "appDeploymentEnv": "green", // 或直接复用version字段的值
      "appVersion": "2.0.0"
    }
  },
  // 其他原有配置...
}

Bot端可以通过turnContext.Activity.ChannelData获取到这些自定义属性（不同Teams版本可能略有差异，建议测试验证），示例代码：

var customProps = turnContext.Activity.ChannelData?["extensions"]?["customProperties"] as JObject;
var appVersion = customProps?["appVersion"]?.ToString();
if (appVersion == "2.0.0") {
    // 路由到绿环境后端逻辑
} else {
    // 保留蓝环境原有逻辑
}

2. 利用Azure Bot Service的部署插槽（Slots） #

Azure Bot Service原生支持Production/Staging两个部署插槽，你可以在同一个Bot注册下，为蓝绿环境分别配置独立的端点和后端：

• 蓝环境：绑定到Production插槽，指向现有生产后端，服务所有1.0.0版本用户
• 绿环境：绑定到Staging插槽，部署新版本后端，仅服务2.0.0版本用户
  这种方式下，不同版本的Teams应用直接指向对应插槽的Bot端点，无需在后端做路由判断，更简洁可控。

二、确保版本更新不被识别为新应用 #

你之前担心新建Azure资源会被当成新应用，这个判断是对的——绝对不要新建应用注册或Bot通道注册，正确的操作是：

• 复用现有应用注册（Azure AD App Registration）和Bot通道注册
• 仅更新Teams应用Manifest的version字段（比如从1.0.0升级到2.0.0），并调整Bot端点（如果用插槽方案）或添加自定义属性（如果用版本标识方案）
• 提交审核时，在Teams应用商店后台选择更新现有应用，而非创建新应用条目

三、蓝绿部署的完整流程 #

结合上面的方案，推荐的端到端流程：

1. 准备绿环境：在Azure Bot Service中创建Staging插槽，部署新版本Bot后端，验证功能正常
2. 打包新版本应用：修改Manifest的版本号和自定义属性/端点，打包成zip文件
3. 提交审核：在Teams应用商店后台，选择现有应用的"更新"选项，上传新版本包，同时在审核备注中说明你的蓝绿部署策略（仅向特定用户推送，不影响现有生产用户）
4. 分阶段推送：审核通过后，利用Teams应用商店的分阶段发布功能，先将新版本推送给指定的测试租户/用户组
5. 验证与切换：确认新版本稳定后，将Staging插槽的后端切换为Production插槽，或者调整后端路由规则，让所有用户的请求指向绿环境，完成蓝绿切换

额外注意事项 #

• 对于Bot指令的行为差异，建议在后端做兼容处理，比如保留旧指令的兼容逻辑一段时间，避免用户突然出现功能异常
• 测试阶段可以通过Teams的**侧载（Sideload）**功能，在内部租户中验证新版本的Bot通信是否能正确区分环境
• 如果使用Azure App Service部署后端，也可以结合App Service的部署插槽，和Bot的插槽做联动，实现全链路的蓝绿部署

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