数据库敏捷版本控制之3个数据库策略

 

背景：

咱们是一个不大的软件开发团队，可是客户遍及全球

关于数据库的版本控制前段时间一直没找到特别好的方式，经过思考和不断实践，最近总结了一个不错的方法，特分享给你们

 

作好数据库的版本控制目的：

同时保证：开发--》测试--》客户基线控制--》数据安全性的须要

 

1号数据库（开发）：主要用于开发使用，因此能持续集成最新的数据库schema（全部开发人员对数据库的每日修改都将集成到该数据库，尽早发现问题）

2号数据库（客户测试）：主要用于，和客户的数据库同步，客户升级过程

• • 1. 获取客户的数据库Schema，放到2号数据库，并记录日期和时间，以及版本号
    2. 比对1号开发数据库和2号客户数据库，生成升级脚本
    3. 用升级脚本升级2号客户数据库，而后进行测试，并修改数据库名字为新的版本号
    4. 测试成功，将升级脚本，打包进安装包，对客户数据库进行升级

3号数据库（基线）：基线数据库，只保存重大版本的release，比方1.0, 2.0等，小的bug fix 版本都不放基线库，也就是基本不更新（本人认为更新频率越低，稳定性和出错几率越小）。

　　　　　　　　　　由于小的bug fix等，这些tracking能够交给TFS或者其它版本控制工具的checkin记录。

 

仔细查看，能够发现，其实开发数据库和基线数据库在数量上有个1对1的关系