我们正在考虑将Flyway集成到我们的应用程序中，但担心它维护自己的版本的方式以及它如何与软件开发生命周期 (SDLC)一起工作。
本质上，我们使用该方法的问题是您维护一组按文件名中的版本分隔的 SQL 脚本，而不是在版本控制中维护一个主干并将该主干发布/标记为特定版本。使用 Flyway，开发人员可以返回并更改与您的应用程序的已发布版本相关的旧迁移脚本，并破坏您已经集成/测试/暂存并交付到生产环境的版本。
我们正在考虑做的是在版本控制下维护项目中的 SQL 迁移（即 my-app-db/trunk/migration.sql），并在 SQL 开发人员声明它已准备好发布时从那里发布/标记（V1 .0.0__blah.sql)。然后清除trunk/migration.sql，以便可以开发和标记下一个1.0.1 或1.1.0 脚本。然后，包装脚本将从标签中导出 SQL 文件，使用该目录调用 Flyway 以执行迁移，并清理导出。
这看起来像是一个有效的观点/方法吗？Flyway 会支持版本控制之类的东西吗？