【发布时间】：2013-06-02 21:39:34
【问题描述】：
目前，我们公司通过手动创建、分发和运行必要的 SQL 脚本来处理所有数据库架构更改。显然，这会导致问题，因为各种机器会零星且稀疏地更新。
我正在研究更现代的方法来处理这个问题，而 Flyway 是目前领先的候选者（尽管如果可以提出令人信服的论据，我们仍然愿意使用 Liquibase）。
正常的流程很简单，工作方式与宣传的一样简单，但我们不知道如何正确解决冲突的迁移脚本。例如，不同个人分支（A 和 B）的 2 个开发人员在不同的迁移（MigrationA 和 MigrationB）中将同一列添加到表中。分支 B 上的开发人员意识到，在他已经在他的数据库上运行 MigrationB 之后，不需要它。不幸的是，此时损坏已经完成，并且已经向数据库 B 中的 schema_version 表写入了一个条目。由于 Flyway 不支持回滚，在这种情况下应该如何响应？
从历史上看，我们一直尽可能避免删除/重建我们的数据库，但是一旦您使用 Flyway，这种心态就已经过时了吗？我们是否应该彻底地创建 DeveloperData 脚本，以便我们可以在出现这些问题之一时删除我们的数据库？在我开始告诉同事我们需要立即丢弃我们的数据库之前，我想确保我以正确的方式处理这个问题。
感谢任何关于人们如何成功切换到 Flyway 的特定输入答案或更一般的解释/示例。
【问题讨论】：
-
虽然我支持 dev/Q 的“干净的石板”方法，但来自经验的警告：不要忘记测试从非干净状态的迁移，以及系统在正常情况下如何反应加载。开发人员倾向于只创建一些测试条目，因此一些错误会被忽略。