我目前正在评估我的组织如何使用liquidbase作为数据库版本控制系统。
然而，我确实对如何将liquidbase理念融入我们当前的工作流程有困难:
目前，我们有我们的应用程序的版本控制下的CREATE和初始填充sql脚本。只要有变化(例如新列)，程序员就调整CREATE脚本并检查更改。由于应用程序代码和SQL脚本位于同一个存储库中，因此DB对象应该始终与应用程序版本保持同步。
另外，对于每个版本，我们维护一个ALTER…当客户升级我们的软件时使用的语句(这种情况比从头开始安装更常见)。
所以我们有两个世界——当前版本的模式对象作为存储库中的CREATE语句，加上从版本1到版本2的必要操作列表(ALTER语句)。
我喜欢的是模式对象的定义总是与软件的版本匹配，因为它们在同一个版本控制存储库中。
我不喜欢(因此寻找替代方案)的是我们必须做的双重工作。此外，由于软件更新的次数比新安装的次数要多，CREATE语句更像是一个文档，但很少应用于数据库。
我所理解的是，liquibase从一个基线开始，然后在小的变化集上运行。因此，我将一次检入基线，然后添加我的小更改集。
随着时间的推移，我可能会有一个带有许多更改集的旧基线。我假设我必须从旧的基线+变更集中手动生成一个新的基线，并从那里重新开始。这听起来让我很困惑。我也不确定我的同事是否会看到与我们目前的工作流程相比的好处。
你有什么建议吗?
这只是我的意见，就这么接受吧。
Liquibase的理念是，你提到的基线是不需要的，只要可以查询数据库，看看有什么变化已经应用到它，所以你的假设，你必须定期生成一个新的基线是不正确的。
让我们比较一下你们的工艺与Liquibase工艺的工作原理。
-
在您当前的系统中，正如您所说，开发人员必须维护两组SQL脚本，您的测试人员必须确保它们是正确的。当用户安装时，您的安装程序必须检测它是否是一个干净的安装，并只运行"创建"脚本。当安装程序检测到升级时，它必须采用不同的路径(可能使用一些复杂的逻辑)来确定运行哪个更改脚本。您的组织必须维护执行升级逻辑的安装程序代码。
-
使用Liquibase，开发人员将只创建数据库脚本的'alter'部分。对于新安装，运行所有Liquibase语句所花费的时间可能比在当前系统中运行create脚本所花费的时间要长一些，但是这样做的好处是减少了重复，从而减少了bug。对于升级安装，Liquibase通过查看已安装的数据库来确定哪些更改已经到位，并且只运行使数据库与正在安装的代码保持最新所需的更改。