database - 持续交付中的生产数据迁移模式

Question

持续交付中的生产关系数据库（和模式）迁移模式是什么？

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

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

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

Answer 1

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

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

步骤1

旧应用程序代码与旧数据库一起工作。

第2步

部署新的应用程序代码，并在启动时迁移数据库。此迁移必须向后兼容，以便旧应用程序代码仍可与新数据库一起使用。这是必不可少的，因为：

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

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

第 3 步

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

Answer 2

将您的数据库更改为单个（原始）sql 文件，然后使用sqlpatch构建迁移脚本。

我通常有一个单独用于数据库的 git 存储库和一个附加的 cd 环境。我通常有一个生产数据库和一个开发数据库，​​当我推送到相应的分支时会自动迁移它们。

这种设置使得为功能分支设置另一个数据库并对其进行试验非常容易。Sqlpatch 负责处理单独的 sql 文件中的所有依赖项，以便我可以轻松地将功能分支合并到另一个分支中。