我们正在考虑在我们的应用程序中集成Flyway，但是关注它维护自己版本的方式以及它如何与Software development life cycle (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以执行迁移，并清理导出。
这看起来像是一个有效的观点/方法吗？ Will Flyway是否支持类似版本控制的东西？
答案 0 :(得分：2)
Flyway 3.0将打开API，使最终用户可以将其扩展到这个方向。开箱即用的SCM集成支持目前尚未列入议程。