我一直在尝试使用Liquibase或DBDeploy。我更喜欢Liquibase，因为它的非sql接口(也就是说，我可以只使用JSON或Yaml更改集)。但是，这两个软件都有一个问题。
<标题> Liquibase工作流h1> 创建了一个主变更日志。它所做的就是includeAll一个包含小文件和小更改集的文件夹。- 我刚刚开始制作delta sql文件，前缀与上面的2相同。
嗯，这个问题太微不足道了，我觉得问这个问题很愚蠢，但这就是问题所在。考虑这个场景:
- 我创建一个分支来处理我的特性，比如，向系统添加订单。
- 我的同事Bob创建了他自己的分支来将产品添加到系统中。
- 当合并时，没有人知道哪个变更集或增量sql将首先运行。这可能破坏数据库。
谢谢。
我使用了几个不同的迁移框架——Liquibase、Rails和c#世界中的Tarantino。每个人都使用类似的策略，将更改记录在单独的文件中。每个人都在一个小团队中(<= 5个开发人员)。
Rails是最教条的文件命名方式，也是我遇到分支冲突最多的地方。这些冲突大多数是基于名称的，而不是数据库中的逻辑冲突。
在使用Liquibase的项目中，我们使用master/include模式，开发人员在分支上完成他们的工作。因为文件名有一个3位数的序列号加上一个简短的描述(例如009-add-customer0index.xml)，所以没有名称冲突。我们避免了数据库级别的冲突，主要是通过相互交谈——日常站立等等。
我们在使用Tarantino时有过类似的经历，尽管它只是使用一个充满文件的目录进行迁移。与Liquibase一样，我们采用了一种命名约定，使事情保持有序。即使两个变更集的数量相同，它们也会有不同的名称，而且99.9%的情况下，这两个变更集的顺序并不依赖于彼此。
对于一个数据点来说，使用Tarantino的项目大约有400个变更集。
(我只知道liquibase -所以我的答案只对liquibase有效)
如includeAll文档所述，文件将按字母顺序运行。所以我希望你的编号应该足以使文件按正确的顺序排列。然而，无论如何，您必须在您和Bob之间同步这些数字，以找出必须首先运行的内容。
我们不使用includeAll虽然。我们手动将文件包含到主变更日志中。因此，无论谁想要更改数据库，都必须将其包含到主更改日志中。如果有两个变更，最后一个来的开发人员必须确保在主变更日志的正确位置包含/合并他的变更。
EDITED -为了解释包含机制，我们使用
在开发中，我们只是把整个数据库搞砸了，让liquidbase在我们改变任何东西时从头开始创建数据库(在我们的开发数据库上)。我们总是将变更集文件签入代码存储库。因此，有了它，我们可以跟踪开发过程中所做的一切，因为我们可以签出每个版本的变更集，并让liquidbase使用它创建数据库。
只有当我们正在开发的版本(或sprint)完成时。然后我们让变更集运行，让它们改变生产数据库。
然后这个循环一次又一次地重复。
这样，只有最终的db更改才会被liquibase跟踪，而不是在开发过程中可能发生的所有尝试。
在开发过程中，您可能会多次更改表，因为您尝试了不同的内容。你添加了一列，然后意识到整个东西都不起作用，所以你再次删除了这列，并添加了另一列。为什么要在databasechangelog中进行所有这些更改?然后它会被不必要的东西填满——就像你害怕的那样。
希望这能澄清问题。但最终你可能会采用完全不同的开发方法。所以请随意使用你需要的液体基础。
没有理由在开发过程中将所有的想法都填满databasechangelog表。只有当我们完成开发并发布一个版本