Flyway 最佳实践：一个大型迁移脚本与多个增量脚本

Posted 2023-03-28

【中文标题】Flyway 最佳实践：一个大型迁移脚本与多个增量脚本

【英文标题】：Flyway best practice: one large migration script vs many incremental ones

【发布时间】：2021-12-01 20:37:37

【问题描述】：

我的任务是使用flyway将一些新的迁移脚本添加到现有应用程序中，大致如下：

为一项逻辑任务更新一张表中的 4 条记录（JIRA 票证 #1） 为另一个逻辑任务更新同一个表中的另一个记录（JIRA 票证 #2） 为（JIRA 票证 #2）更新另一个表中的记录

有两种选择：

将更改 3 保存在单独的迁移脚本中。 将所有更改集中在一个包含所有内容的大型脚本中。

为了逻辑描述，我喜欢将这些更改保留在 3 个单独的迁移脚本中，以防任何这些脚本执行失败，我不必创建另一个大型更正脚本来修复失败，因为它可能会变得非常混乱。

另一方面，这 3 个任务都属于同一个工作（更大的父 JIRA 任务）并一起投入生产。

有人可以分享他们关于最佳做法的经验和意见吗？请保留 3 个迁移脚本或将它们放在一起，如果可能的话，请说明每种方法的优缺点？

我找到了这篇文章，但它没有说明我的具体查询： https://dbabulletin.com/index.php/2018/03/29/best-practices-using-flyway-for-database-migrations/

【参考方案1】：

这将是部分意见，所以我们只需要在 SO 和规则内处理它。

我绝对会把它分解成更小的脚本。这有两个原因。首先，当其中一组更改向南时（是的，可能不是，但如果），如果它在自己的脚本中，您可以更容易地将其与所有其他更改分开。当然，您仍然可以对更改进行分组，使其全部为 7.1、7.2、7.3（或其他），但如果已经拆开，那么拆开东西会更容易。

其次，如果您遇到这样一种情况，即通过挑选樱桃进行零碎部署，您还需要将脚本分解为单独的更改集。原因同上。

这并不是说我永远只做个别的改变。但是你列出的那种完全不同的变化，那些彼此没有直接关系的变化，实际上可以分开，那些，我会分开。

部分是意见，部分是对事物如何分崩离析或需要改变的理解。我希望这是 SO 规则中的答案。

【参考方案2】：

这更像是一个铁的事实，但我通常遇到的“最佳实践”是将脚本保留为功能或依赖命令。这样，如果某个命令中断了迁移，您不会损失太多进度，并且可以帮助您查明问题所在。

【讨论】：

您的答案可以通过额外的支持信息得到改进。请edit 添加更多详细信息，例如引用或文档，以便其他人可以确认您的答案是正确的。你可以找到更多关于如何写好答案的信息in the help center。