背景：

我们是一个不大的软件开发团队，但是客户遍布全球

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

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

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

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的关系