数据库线上更新往往是一个比较麻烦的问题，由于线上数据库已经用在了生产环境中其中存在了大量的真实数据，因此当数据库结构发生改动时，不能像测试数据库一样可以随时清空数据库，修改数据库的表结构而不影响任何的用户，在线上数据库中对于表结构的任何更新都有可能对于用户带来非常大的干扰
目前而言，如果涉及到了数据库的变更，而项目又已经上线运行了的话，那最好的方式就是在开发的时候对于数据库的变更就定义好对应的DDL语句以及数据迁移的SQL脚本，并在CICD流程中将对应的脚本先应用在开发或测试数据库中保证数据的正确性，最后再在上线更新版本的时候执行对应的DDL语句以及数据迁移脚本，但是这同时又引入了以下几个问题：
-
不同的开发人员在开发产品特性时，都有可能更新数据库（添加新表，新的约束等）。当开发人员完成工作并提交代码时，代码会被合并到主分支并在测试服务器上执行单元测试与集成测试。那么应该在哪个环节来执行数据库的更新操作呢？由QA 部门手工执行sql 脚本？或者开发程序自动执行数据库更新？另外又该以什么顺序来执行这些更新脚本？这些问题同样存在于生产环境
-
不同的客户和测试环境上都部署着不同版本的产品。当他们需要升级他们的产品到新的版本时，不仅需要让他们的管理员可以升级产品到新的版本，同时需要保留他们的已有数据。在升级产品的步骤中，如何清楚地知道客户数据库的当前版本以及需要在该数据库上执行哪些数据库更新脚本从而来更新数据库表结构与数据库中已存在的数据呢？
为了保证数据库结构变化的可回滚以及数据迁移的一致性，往往会采用特定的工具进行数据库版本管理，常用的工具是Flyway，它一个是独立于数据库的应用、管理并跟踪数据库变更的数据库版本管理工具，它既支持Java语言编写对应的代码同时也支持运行SQL脚本语句因此对于Java开发人员而言可以快速地上手，同时它官方也有对应的Maven插件，从而可以方便地集成在CICD构建流程中以实现数据库结构的自动化变更与验证
