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