问如何管理Flyway变更的开发？

EN

作为对Julia答案的补充，问题中有趣的短语是“但由于这从来没有离开过开发，这似乎是一个糟糕的决定”。这是一个很好的观点:您的场景是您所做的更改测试失败，因此不应该出现在主要的迁移“叙述”中。如果您可以采用分支/合并策略，仅当您的分支上的单元和集成测试完成时才将迁移添加到“开发”分支，那么您就可以避免这种情况。

我将在这里更详细地介绍这一点，Branching and Merging in Database Development using Flyway。只要您可以为将数据库的分支版本构建到确切版本(分支点的版本)的分支创建初始迁移文件，Flyway就可以非常容易地管理这一点。如果在数据库的同一部分或依赖的数据库对象上存在并发开发，合并过程可能会很棘手，但对于数据库开发通常是这样的。

在Flyway上有一些文档，讨论如何使用Spawn通过创建临时数据库并为您处理这些数据库的管理来补充您的开发和测试环境。此页面的一部分explicitly documents "undoing mistakes" and "restoring to previous states"。

这听起来就像你想要做的那样。

这样，在您意识到迁移脚本应该是不同的之后，您可以运行spawnctl reset data-container <your_container>将数据库恢复到原始状态。然后，您将能够使用已修复的迁移脚本再次运行flyway migrate，就好像最初的错误迁移从未部署过一样。

这应该比手动重置数据库状态容易得多，而且它的好处是让您准确地回到开始的位置。您也可以在开发过程中创建任意的保存点，这样您就可以重置回各种已知良好的状态。

简单的解决方案有一件很重要的事情-它将准确地跟踪您的dev数据库经过了什么过程才能达到它的当前状态，并在其他环境中准确地重播；因此，您不会因为没有正确地滚动更改而出错。

另一个解决方案是为Flyway编写互补的撤销脚本(注意:付费功能)，这样你就可以上下浏览版本历史，直到你满意为止。

或者，这将在没有数据库重置的情况下工作:在DEV中：

V1__1.sql：CREATE TABLE blah ...

V1__2.sql：ALTER TABLE blah ...

然后，当你高兴的时候，改变脚本以符合现实：

V1__1.sql：CREATE TABLE blah (new version) ...

V1__2.sql：<commented out>

这可以在生产环境中运行，在开发环境中运行flyway repair以重新对齐文件校验和。或者，以类似的方式，您可以维护两组脚本，一组用于开发，另一组用于生产，其中只包含您想要提升的更改。这两种方法都不能防止dev和prod无意中分离。正如评论中提到的，重置dev数据库是一件痛苦的事情，这本身就是一种味道，值得重新审视。