内部WPF应用发布策略优化及金丝雀发布数据库适配问题咨询

我所在团队曾落地过完全匹配该技术栈的内部应用发布方案，核心原则是数据库变更必须向前兼容至少1个正式版本，所有设计都围绕该原则展开，不需要复杂的中间件，适配小团队的资源现状：

1. 数据库变更前置规则 #

• 所有破坏性变更（删表、删字段、修改字段类型/非空约束）禁止在金丝雀验证阶段直接执行，必须拆为至少2个发布批次：
  • 第一批次（金丝雀发布前）：先新增需要的字段/表，同步兼容旧版本应用的读写逻辑，例如需要修改字段名时，先新增新字段，同时增加双写逻辑同步旧字段数据到新字段，该阶段新旧版本应用可同时正常运行
  • 第二批次（全量发布完成、所有用户升级到新版后）：再下线旧字段双写逻辑，删除废弃的旧字段/表
• 所有SQL变更脚本必须配套对应回滚脚本，存储在DevOps流水线的指定目录，禁止无回滚方案的变更上线
• 可以配合Flyway这类轻量数据库版本管控工具，把SQL脚本按版本号排序，流水线自动按顺序执行，避免手动执行脚本出错

2. 金丝雀阶段数据库隔离方案（2种可选，按业务风险选择） #

方案A：同库标记隔离（优先推荐，无额外运维成本） #

• 所有金丝雀版本产生的新业务数据，通过内置的版本标记字段区分，例如在涉及新逻辑的业务表中新增app_version字段，金丝雀版本写入数据时自动打上当前版本号，旧版本应用查询时自动过滤高于自身版本的标记数据，避免新旧版本数据互相污染
• 涉及灰度验证的新业务关联表，可单独绑定用户组权限，仅金丝雀用户组有权限读写对应新表/新字段，旧版本用户完全无感知

方案B：临时金丝雀库（仅适合涉及核心数据修改、风险极高的版本） #

• 发布前从生产库同步全量数据到临时金丝雀库，金丝雀版本应用单独配置数据库连接字符串，所有操作均走临时库，验证通过后，提前执行数据同步脚本把临时库产生的有效新数据同步回生产库，再推送全量版本
• 该方案需要提前做好主键冲突、数据一致性校验的逻辑，避免同步出错

3. ClickOnce与DevOps流水线配套适配 #

• 将用户划分为金丝雀用户组和全量用户组，ClickOnce设置两个独立发布地址：金丝雀地址仅对核心验证用户开放，全量地址对所有用户开放，两个版本的配置文件单独配置对应的数据库参数（例如新字段开关、数据库连接字符串等）
• 数据库变更脚本完全集成到DevOps流水线：金丝雀发布前自动执行兼容版本的SQL脚本，全量发布完成后自动执行废弃资源清理脚本，全程无需手动操作

4. 风险兜底机制 #

• 金丝雀验证阶段如果发现数据库相关问题，直接回滚金丝雀用户的应用版本到上一个稳定版即可，由于提前做了向前兼容设计，回滚后旧版本应用可完全正常使用当前数据库结构，不会出现数据异常
• 每次发布前自动触发生产库全量备份，出现极端问题可在10分钟内恢复到发布前的状态

内容的提问来源于stack exchange，提问作者Tim D'haeyer