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

Question

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

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

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

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

Answer 1

Flyway适用于连续交付/部署。许多客户在所有环境中使用它，包括生产。

跨环境级联DB迁移的一个最重要的事情是有一个3个步骤：

步骤1

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

步骤2

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

• 然后你可以做滚动升级，每次升级一个节点，直到当新的坏
所有节点都具有新的应用程序代码立即
• 回滚到旧的应用程序代码

此步骤可能涉及兼容性视图和触发器以执行此项工作。

步骤3

更改已证明的工作之后，应用程序代码的下一个版本得到 必要DB迁移部署在一起以丢弃任何剩余的过时的（来自步骤1）和兼容性（从步骤2）结构。

Answer 2

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

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

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