什么是持续交付生产环境中的关系数据库（和架构）迁移模式？
在许多传统开发中，DBA 会从当前发布周期中创建的许多较小脚本中安排一个大型迁移脚本。但在 CD 中，开发人员可能希望现在将更改推送到生产环境，而不是等待与其他脚本一起编译它们。
我知道 rails-migration 但对我来说使用原始 sql 脚本看起来更合理。
我还看到了像 flyway 这样的工具来管理迁移，但我还没有看到很多人在生产中使用它们。这就是为什么我想知道这里的常见做法是什么。
【问题讨论】：
标签： database postgresql continuous-deployment flyway
Flyway 非常适合持续交付/部署。许多客户在包括生产在内的所有环境中使用它。
跨环境级联数据库迁移最重要的一点是有一个 3 步流程：
第 1 步
旧的应用程序代码与旧的数据库一起工作。
第 2 步
部署新的应用程序代码，并在启动时迁移数据库。此迁移必须向后兼容，以便旧应用程序代码仍可与新数据库一起使用。这是必不可少的，因为：
此步骤可能涉及兼容性视图和触发器来完成这项工作。
第 3 步
在更改被证明有效后，下一个版本的应用程序代码将获得 与必要的数据库迁移一起部署，以丢弃任何剩余的过时（来自第 1 步）和兼容性（来自第 2 步）的结构。
【讨论】：
将您的数据库更改为单个（原始）sql 文件，然后使用sqlpatch 构建迁移脚本。
我通常有一个单独用于数据库的 git 存储库和一个附加的 cd 环境。我通常有一个生产数据库和一个开发数据库，当我推送到相应的分支时会自动迁移。
这种设置使得为功能分支设置另一个数据库并进行试验变得非常容易。 Sqlpatch 负责处理单独的 sql 文件中的所有依赖项，以便我可以轻松地将功能分支合并到另一个分支中。
【讨论】：