Laravel迁移x Flyway迁移

Question

在过去的两年里，我使用CodeIgniter作为PHP框架，并使用Flyway来迁移项目中的.sql代码。它工作得很好，我推荐它。

然而，一个新的项目需要使用Laravel作为框架。所以，当我研究Laravel时，我发现它有一个迁移功能。

有没有人同时使用这两种方法，并能说出每种方法的优点和缺点？

在我的研究中，我发现了下面的列表：

Laravel：-如果你想从mysql迁移到postresql或其他数据库，就不那么痛苦了；-可以使用原始SQL，但这是不自然的；-如果你改变了PHP框架，你将需要转移迁移策略；

Flyway -非常容易使用；-它只使用原始的SQL，具有所有的优点；-保持PHP和数据库代码分离；-从mysql转换到其他数据库是痛苦的；

现在，我使用Mysql和Jenkins实现自动化。

还有什么建议吗？

Answer 1

我想你可以两个都用。当您想要随着时间的推移跟踪架构更改并确保这些更改不会破坏您的生产环境时，Flyway功能非常强大。它还在您的生产环境中提供了一些安全性，防止当某个“聪明的”devops人员修改生产数据库来“修复”问题时发生DB升级。

确保以正确的顺序跟踪、验证和应用数据库更改是它如此强大的原因。而且，作为开发人员，您不必围绕跟踪数据库本身中的模式更改编写大量基础设施。Flyway会帮你处理的。

也就是说，它可能不是在测试周期中插入数据的最佳/最简单/最方便的方法。混合方法可能更简单，但我甚至在java/spring环境中集成了flyway来验证模式更改并填充测试数据。

开发人员经常必须进行模式更改，而flyway在提供防止冲突并使道路平滑和可验证的基础设施方面非常出色。

因为它在数据库中的版本控制，所以可以审计更改并验证当前数据库的版本-即，应用了哪些模式更改以及何时应用。我不能告诉你有多少次我在没有这样的跟踪的软件项目上工作。这使得在没有一系列查询和调查的情况下无法确定数据库处于什么状态。通常在发现flyway之前，我参与的项目中的开发人员会滚动他们自己的数据库版本控制，因为如果没有它，就不可能知道部署软件的人是否遗漏了一个步骤，从而导致升级失败。“哦！我忘了运行添加了新列约束的sql脚本！”

Flyway利用了所有的不确定性，并使其变得确定。如果Laravel的迁移特性和flyway一样健壮，那么最好使用框架中的特性。但它可能不会，混合方法会给你带来最好的整体安心。