数据库版本化的最佳实践

保持数据库脚本的可追溯性是非常困难的，数据库的 Schema 通常会在不同环境里出现不一致，导致上线部署失败，并且出现数据不一致的问题，甚至会出现在某些数据库里丢失某些核心数据的现象。

如果你是应用软件的开发者，情况会变得更糟，因为每个客户会有自己的数据库实例，不同的版本结构各不相同，在这样的项目里，保持客户的数据库的追溯性更加困难。

现在让我们来看看数据库版本化的最佳实践是如何解决这个问题的。

数据库版本化:问题

当你从一个程序员的角度来看一个还没有部署到生产环境的应用，是没有任何这类问题的。你只需要按需修改你的数据库 Schema 即可。

当你的应用程序跑在生产环境里，开发会告诉运维的同事去多个数据库进行人工的修改。随着开发的变更频率越来越快，数据库变更的速度也越来越快，数据库变更出现错误的几率也越来越大，导致陷入上线失败，回滚困难的两难境地，您也一定经历过这样的场景。

数据库版本化的最佳实践

数据库版本化的最佳实践推荐这本书：Refactoring Databases （Scott Ambler 著）

最佳实践 #1:对待数据库的 Schema 要像对待普通的程序代码一样。这意味着我们需要将应用程序代码和数据库 Schema 都用代码管理系统来管理。

注意，这条规则仅仅适用于 Schema 和必备的初始化数据。初始化数据是启动系统必备的数据，例如中国省份列表等等。

最佳实践 #2:必须将每次数据库的 Schema 变更记录在代码管理系统，初始化数据的修改也应该被记录为不同的版本存起来。这意味着每次修改数据库脚本，我们就会创建一个独立的 SQL 文件。如果你的 SQL 脚本既修改了 Schema，又修改了初始化数据，那么应该将这些变更放在不同的文件里。

这个规则是构建成功的数据库版本化系统的核心思想。很多项目只是将数据库当前的 Schema 快照存在版本管理系统里，但它缺少数据库变更的详细记录，同样的，初始化数据的变更也完全没有记录。

最佳实践 #3:每个 SQL 脚本文件在部署到生产环境或者是预发布环境后，必须是不可变的。

将所有数据库的变更存在单独的文件里的目的就是为了更好的做追溯。如果我们修改现有的数据库脚本，那么我们就会失去数据库版本化的所有好处。发布应用时，也将数据库脚本同时发布，如果你需要回滚已经发布的数据库变更，你应该下一个另外的脚本来做这个事情。

最佳实践 #4:所有数据库 Schema 的变更和初始化数据必须使用脚本自动化部署，绝对不能依赖人工部署。

如果我们之间修改数据库 Schema，而不使用变更脚本，那么数据库版本化也就没有意义。所有我们所有的数据库变更都应该被创建的 SQL 脚本执行。

最佳实践 #5: 团队里每个开发者应该有自己独立的开发库。

通常，团队最开始会共用一个数据库在他们的开发环境里。这在开始阶段很好，但当数据库变得很大，同步修改的任务变得频繁之后，会带来很多问题。

程序员提交的数据库变更通常互相不兼容，所以每个程序员最后有独立的数据库来避免频繁的数据变更冲突。开发者同步修改数据库 Schema 时，可以通过代码管理系统来合并冲突，就像合并 Java 代码冲突一样。

如果你的代码库里有多个分支，你也可能需要为不同的分支建立不同的数据库，取决于每个分支的差别有多大。

这样做有什么好处？

这样做到底有什么好处？最重要的优点是，我们再也不需要担心数据库不一致的问题。自动化的升级到任意版本可以完美解决这个问题。如果你的部署环境有多个数据库，而用户每个数据库都有独立的版本，如果没有数据库版本化的系统，管理起来会变成灾难。

另一个优点是这种实践为数据库变更获得了高内聚的能力。它意味着每个数据库的重大变更都反映在一个文件里，而不是散落在各个表里面。

SQL 升级脚本也获得了高内聚的能力，我们可以清楚的看到某个功能的上线，依赖于哪些 SQL 脚本。如果我们需要下线一个变更，我们也清楚的知道怎么做数据库的回滚。

本文中的方法即使你之前没有这样使用，也可以马上开始实践，只需要将现在的数据库 Schema 变成一个基准版本 v1.0_init.sql，然后开始将所有的变更记录在升级版本的 SQL 文件里。很多工具已经开始支持这种数据库版本化的功能，其中比较主流的是 LiquiBase 和 Flyway。

其中，Flyway 是基于 SQL 文件的版本管理，任何项目使用的门槛非常低，因为你不需要修改这些 SQL 语句做版本化。当然它也带来一个缺点，如果你想迁移现有的数据库到其他引擎的数据库，Flyway 的版本就很难重用。它也是基于 Java 的开源软件，你可以比较方便的去扩展。

LiquiBase是基于 XML 的数据库版本化工具，它为每次数据库变更提供 Changelog 记录，通过这个 Changelog，你可以将数据库脚本迁移到其他类型的数据库，无需做任何改变。它也提供了一个 jar 文件，自动化生产所有需要的 Xml Changelog。

参考资料：http://enterprisecraftsmanship.com/2015/08/10/database-versioning-best-practices/

扫码关注我们！

关于JFrog

世界领先DevOps平台

公司成立于2008年，在美国、以色列、法国、西班牙，以及中国北京市拥有超过200名员工。JFrog 拥有4000多个付费客户，其中知名公司包括如腾讯、谷歌、思科、Netflix、亚马逊、苹果等。关注 JFrog，感受原汁原叶的硅谷技术！我们不仅仅提供最优秀的产品，也提供最优秀的持续交付平台的解决方案，详情请洽info@jfrogchina.com