【发布时间】：2013-09-21 05:18:27
【问题描述】：
我们正在考虑将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 以执行迁移，并清理导出。
这看起来像是一个有效的观点/方法吗？ Flyway 会支持版本控制之类的功能吗？
【问题讨论】：
-
仅供参考，从 4.2 版开始，据我所知，
Validate命令会验证现有脚本，以查看它们在应用后没有被更改或删除。显然，这是通过检查每次迁移的 checksum calculated and recorded 来完成的。
标签： database migration flyway sdlc