Visual Studio数据库项目dacpac构建部署流水线版本号存储方案咨询

两种方案的定位与优劣对比 #

二者并不属于互斥关系，而是面向不同需求的实现路径，不存在绝对的优劣，你可以根据团队场景单独使用或者组合使用：

• 扩展属性存储方案
  该方案是完全自定义的轻量实现，优缺点如下：
  • 优点：灵活性极高，除版本号外还可存储构建commit哈希、部署人、发布说明等自定义元数据；不依赖DAC框架能力，所有SQL Server版本均支持；权限要求低，仅需目标库的ALTER权限即可操作，兼容受限部署环境；查询便捷，直接执行SELECT * FROM sys.extended_properties WHERE name = 'DBVersion'即可读取
  • 缺点：需要自行维护预/后部署脚本实现版本的更新逻辑，版本与dacpac元数据无强绑定，若部署流程管控不到位可能出现版本不一致的问题
• DacVersion + RegisterDataTierApplication 方案
  该方案是微软DAC生态自带的标准化实现，优缺点如下：
  • 优点：与dacpac原生元数据强绑定，无需自行编写版本维护脚本，部署时SQL Server自动将版本写入sysdac_instances系统表；自带版本校验能力，可直接基于系统表实现低版本拦截、增量部署校验等逻辑；适配微软全栈工具链，SSMS、Azure Data Studio等工具可直接读取数据层应用版本
  • 缺点：依赖DAC框架支持，部分受限云数据库实例、老旧SQL Server版本无法使用；需要服务器级别的注册权限，权限管控严格的环境可能无法申请；可存储的元数据固定，无法自定义添加额外的构建/部署维度信息

第三种可选版本存储方案 #

行业内还有一种非常常用的实现方式：单独创建版本控制表，比如dbo.DatabaseDeploymentHistory，表结构可设计为包含版本号、语义化版本标识、构建ID、commit哈希、部署时间、部署人、变更说明字段，每次部署完成后通过后部署脚本插入一条新记录。
该方案的优势是可留存全量部署历史，方便后续排查问题、回溯变更，无需依赖系统表或扩展属性，兼容性极强；缺点是需要自行维护表结构，首次部署时需要提前创建该表。

DevOps与DBA领域相关最佳实践 #

• 版本号统一使用语义化版本规则，格式为主版本.次版本.修订号.构建号，构建号直接复用CI流水线的全局唯一运行ID，避免版本重复
• 所有版本号均由CI流水线在构建阶段动态注入，不要硬编码到数据库项目的代码中，可直接将流水线的构建号变量赋值给DacVersion参数，或注入到扩展属性/版本表的更新脚本中
• 版本信息必须与代码仓库commit强绑定，将commit哈希纳入版本元数据存储，出现线上问题时可直接回溯到对应代码提交
• 部署前增加前置校验逻辑，读取数据库当前已部署版本，若待部署的dacpac版本低于已部署版本直接拦截，避免降级操作引发的数据损坏
• 若使用DAC注册方案，需定期将sysdac_instances中的版本记录同步到部署台账，避免服务器级元数据丢失后无法核对版本
• 所有版本变更操作均留存日志，部署完成后将版本号、部署环境、部署结果同步到统一的变更台账中，方便跨团队核对

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