基于Flyway的数据库版本控制实战

背景

大家平时在开发过程中，会用代码管理工具来进行我们的代码管理。如Git这些，使用这些版本控制系统能轻松地帮我们

• 解决不同开发人员之间的代码冲突

• 处理版本回退

• 实现软件代码的CI/CD等

那大家考虑过么，针对数据库脚本怎么办的呢？有如下几个问题？

• 我们如何比对多环境的数据库版本是否一致？

• 几个人同时修改一个表，如何进行协同合作？

• 我们如何确定该脚本是否在生产环境运行过？

针对上述这些问题，可以通过一些Database migrations工具来进行解决，而Flyway就是其中一种工具!

那么，目前为止介绍flyway的文章，都紧紧的和java生态关联在一起了，不具备工程化的能力！

因此，才有了本文诞生，可以迅速在生产上搭建出工程化的数据库版本控制工具。

正文

约定

ok，为了避免歧义，我们先达成一些约定，避免后文看着看懵了！我们在开发过程中呢，一般有如下环境:

Dev环境：开发环境，该环境是程序猿们专门用于开发的环境，配置可以比较随意，主要是为了开发调试方便，例如可用来前后端联调等。

Test环境：测试环境，该环境一般为测试人员所用，主要验证我们所实现的功能是否满足我们业务所要求的规格。

Uat环境：用户验收测试环境，该环境一般为真实用户所用，例如你是给XX企业开发的系统，那么该环境就是给XX企业的人员进行验收测试环境

Staging环境:预发布环境，该环境一般是生产环境的镜像环境， 测试人员在Staging 环境上对新版本做最后一轮验证, 通过后才能deploy到生产环境上

Prd环境:生产环境，该环境是正式提供对外服务的环境。

那么我们在开发过程中，在各个环境有对应分支，每次对应分支的代码变动时，Jenkins流水线会自动触发，将对应的分支代码Build到对应的环境上。一般情况下，Dev环境对应的就是Dev分支，Test环境对应的就是Test分支，而Staging环境和Prd环境，对应的是基于master分支拉出的版本分支。

一般来说，版本分支有三位版本号，如1.3.0，第一位代表重大变更，例如涉及到代码框架替换这种级别的变更，改第一位。每次功能发布，改第二位。每次有紧急BugFix版本，改第三位～可能不同公司有不同的规范，但是这和本文关系不大。

那么开发流程一般如下

ok，