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

背景

大家平时在开发过程中，会用Git来进行我们的代码管理。如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，到上面为止，都是大家懂的一些常识，可能流程上不同公司会有一些不大一样，例如有的公司上test环境，一定是从dev分支合过去，并不是从feature分支来合。大家在落地过程中，可以按照自己公司的流程进行对应修改，当然这并不影响后文阅读。

下面我们简单的介绍一下Flyway，不墨迹，几句话就能讲明白！

Flyway原理

Flyway在官网上提供了多种执行方式，但是我们要在项目中工程化的使用，我只推荐一种，就是命令行的方式～

那么，我只教一个命令就行了，只需要会这个命令，就能在项目中搭建出工程化的数据库版本控制工具。（画外音：么错，孤独烟老师就是这么diao，一个命令就能搞定一切～）

flyway -configFiles=config/flyway.conf migrate