连续交付中的生产数据迁移模式

Question

连续交付中的生产关系数据库(和模式)迁移模式是什么？

在许多传统开发中,DBA在当前发布周期中创建的许多较小脚本中安排了一个大型迁移脚本.但是在CD中,开发人员可能希望将更改推送到生产环境,而不是等待用其他脚本编译它们.

我知道rails-migration,但对我来说使用原始sql脚本看起来更合理.

我也看过像flyway这样的工具来管理迁移,但我还没有看到很多人在生产中使用它们.这就是为什么我想知道这里的常见做法是什么.

Answer 1

Flyway非常适合持续交付/部署.许多客户在所有环境中使用它,包括生产.

跨环境级联数据库迁移的最重要的一点是要有一个3步骤的过程:

步骤1

旧的应用程序代码与旧的DB一起使用.

第2步

部署新的应用程序代码,并在启动时迁移数据库.此迁移必须向后兼容,以便旧应用程序代码仍可与新数据库一起使用.这很重要,因为:

• 然后,您可以进行滚动升级,一次升级一个节点,直到所有节点都有新的应用程序代码
• 如果新应用程序代码损坏,则立即回滚到旧应用程序代码

此步骤可能涉及兼容性视图和触发器来完成工作.

第3步

在证明更改有效后,下一版本的应用程序代码将与必要的数据库迁移一起部署,以丢弃任何剩余的过时(来自步骤1)和兼容性(来自步骤2)结构.