如何避免Bicep重部署AppService时清空ZIP部署内容？

核心原因 #

重新部署Bicep模板时，Azure资源管理器会严格按模板定义覆盖资源属性，包括部署中心（Deployment Center）的配置。如果模板未明确保留部署后的状态，或包含会重置部署记录的属性，就会导致应用内容被清空。

解决方案 #

1. 使用Bicep的ignoreChanges忽略部署相关属性 #

这是最直接的解决方式，通过ignoreChanges告知Azure资源管理器，后续部署时跳过指定属性的更新，保留现有状态。

在App Service资源定义中添加该配置，示例如下：

resource appService 'Microsoft.Web/sites@2023-01-01' = {
  name: appServiceName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    siteConfig: {
      // 保留你的基础配置，比如运行时版本、端口等
      linuxFxVersion: 'PYTHON|3.11'
    }
  }
  // 忽略会被部署操作修改的属性
  @ignoreChanges([
    'properties/siteConfig/scmType'
    'properties/siteConfig/appSettings'
    'properties/deploymentLocalCacheEnabled'
    'properties/webSocketsEnabled' // 若部署时会修改这类属性也可添加
  ])
}

根据实际部署场景调整ignoreChanges中的属性列表，确保覆盖所有部署过程中会变更的配置项。

2. 避免在模板中硬编码部署相关属性 #

如果Bicep模板中明确设置了scmType（比如设为None），重新部署时会强制覆盖DevOps部署后的配置。确保模板中不包含这类会重置部署状态的硬编码属性，让Azure保留现有值。

3. 分离基础设施与应用部署流程 #

将App Service等基础设施的Bicep部署，和Azure DevOps的应用内容部署拆分为独立管道：

• 基础设施管道仅在需要调整资源配置（比如扩容计划、修改运行时）时执行
• 应用部署管道仅负责推送代码/内容，不触碰基础设施模板
  从流程上彻底避免两者冲突。

4. 借助部署槽位隔离状态 #

如果业务场景允许，使用App Service的部署槽位功能：

• 将应用内容部署到测试槽，验证后再交换到生产槽
• 重新部署基础设施模板时，生产槽的部署记录和应用内容不会被影响，因为槽位状态是独立的

注意事项 #

• 测试ignoreChanges配置时，先在非生产环境验证，确保重新部署Bicep后应用内容和部署记录完整保留
• 定期检查模板中的属性，避免新增会覆盖部署状态的配置项

内容的提问来源于stack exchange，提问作者Mike-E