Azure App Service预生产槽（ExampleName/master）交换前应配置哪些设置？

作为过来人，我完全理解你作为新手的困惑——毕竟预生产槽的定位和配置直接关系到生产环境的稳定性。结合Azure的最佳实践和实际部署经验，给你理清楚这个问题：

核心原则：预生产槽要「模拟生产，但隔离风险」 #

你的判断**“不应直接使用生产环境的可写资源”是完全正确的**，但也不能直接用Staging环境的依赖，原因如下：

• 如果用Staging环境的数据库/服务：Staging通常是早期测试环境，资源配置、数据量、业务场景和生产差异很大，你在Staging槽验证通过的代码，到生产环境可能因为数据量级、依赖性能问题出现故障，失去了预生产槽的意义。
• 如果直接用生产环境的可写资源：预生产槽里的新版本代码可能存在bug，一旦写入生产数据，会直接污染生产环境，造成不可逆的损失。

推荐的配置方案 #

针对你这种ExampleName/master作为预生产槽、之后要和生产槽交换的场景，最优做法是：

1. 对齐生产环境的配置框架：预生产槽的环境变量、连接字符串的结构要和生产槽完全一致，比如生产用DB_CONNECTION_STRING，预生产也用同一个变量名，只是变量值做隔离。
2. 数据库等关键依赖的隔离处理：
   • 选项一：给生产数据库创建只读权限的账号，把预生产槽的数据库连接字符串设置为这个只读账号。这样你可以验证新版本代码在生产真实数据下的查询、展示逻辑是否正常，同时不会有写入风险。
   • 选项二：创建一个生产数据的镜像库（定期从生产库同步结构和数据，比如每天凌晨同步一次），预生产槽连接这个镜像库。这种方式更适合需要验证写入逻辑的场景（比如数据更新、新增），但要注意同步频率，保证镜像库的数据尽量贴近生产。
3. 利用Azure槽的「槽位特定配置」：在Azure门户里，把预生产槽的数据库连接字符串标记为「槽位特定」。这样当你和生产槽交换时，预生产槽的这个配置不会被交换到生产槽，生产槽依然使用原来的生产数据库连接，避免配置混乱。

补充你的CI/CD流程优化建议 #

目前你的分支对应槽的配置是合理的，但可以再优化一步：把生产分支（通常是main，如果你的生产分支就是master也没问题）关联到这个预生产槽，这样每次生产分支的代码变更都会先到预生产槽验证，没问题再交换到生产槽，完全符合Azure官方的最佳实践。

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