如何在Azure上为每个PR的React应用部署独立访问URL？

这个需求完全可以实现，你提出的为每个PR动态创建App Service、合并后销毁的方案是可行的，除此之外还有多个更轻量化、成本更低的落地方式可选：

方案1：动态创建/销毁独立App Service（原思路落地） #

• 在CI/CD流水线的PR触发阶段，调用Azure CLI创建新的App Service，命名规则按你的需求设为my-react-app-${BUILD_NUMBER}即可，平台会自动生成对应格式的访问域名。创建命令参考：

  az webapp create --resource-group <你的资源组名称> --plan <你的App Service计划名称> --name my-react-app-${BUILD_NUMBER} --runtime "NODE:18-lts"
  

• 完成React应用构建打包后，将产物直接部署到刚创建的App Service中，可自动将访问URL评论到对应PR页面，方便相关人员测试。
• 配置PR合并/关闭触发的流水线任务，调用Azure CLI删除对应PR的App Service，避免资源浪费。可以额外配置兜底定时任务，清理超过7天未处理的PR对应App Service，避免流水线触发失败导致的资源残留。

方案2：使用App Service部署槽位（更轻量化、成本更低） #

不需要创建多个独立App Service，依托同个App Service下的部署槽位功能即可实现，仅需支付1个App Service的费用：

• 在PR触发流水线时，为对应PR创建专属部署槽位，槽位命名按pr-${PR_ID}规则设置，平台会自动生成https://<原有App Service名称>-pr-${PR_ID}.azurewebsites.net格式的独立访问URL。创建命令参考：

  az webapp deployment slot create --name <现有App Service名称> --resource-group <你的资源组名称> --slot pr-${PR_ID}
  

• 构建完成后将React产物部署到对应槽位即可，完全不影响生产环境的运行。
• PR合并/关闭时直接删除对应槽位即可，资源清理逻辑更简单。

方案3：Azure Static Web Apps原生PR预览（纯静态React应用最优解） #

如果你托管的是无后端依赖的纯静态React应用，直接迁移到Azure Static Web Apps托管即可：

• 平台原生支持PR预览功能，无需自行编写资源创建、销毁的流水线逻辑，开启配置后每个新PR都会自动生成独立预览环境，分配唯一访问URL。
• PR合并后平台会自动销毁对应预览环境，无需额外维护资源生命周期。

内容的提问来源于stack exchange，提问作者Gustavo Mendonça