如何在使用功能分支时使用Flyway

时间:2012-02-29 10:03:24

标签: java database flyway

我们最近开始使用功能分支来处理我们所处理的每个故事。这些是尽可能独立的,然后我们的项目经理决定哪些故事将构成一个版本。这意味着我们确实知道故事最初投入生产的确切顺序。

Flyway有没有一种标准的处理方法?我已经阅读了FAQ,它讨论了对生产数据库的更改是如何线性的,这是正确的。但是我不确定团队成员如何决定在他们的功能分支工作时为他们的迁移提供哪些版本号。当我们在发布之前合并到集成分支和master时,我们还需要手动重命名迁移文件。

3 个答案:

答案 0 :(得分:26)

您不能拥有与您将获得的版本号相同的迁移scrtipts:

  

使用版本“x.y.z”找到了多个迁移(违规者:SQL ...)

以下是我建议的解决方法:多个开发人员正在使用相同的版本,比如说1.0但是在不同的功能上。我猜您正在使用一些问题跟踪器,为每个问题添加ID,例如FOO-16。当开发人员处理该问题时,迁移脚本称为V1.0.16__my_greatest_feature.sql。这种方式(假设每个功能/分支都有自己的问题)没有冲突。

此外,我假设数据库迁移脚本是独立且不重叠的,但如果不是这种情况,则在将所有内容合并到稳定版本时会遇到问题。

因此,在稳定版本中,您有几个有差距的迁移脚本,例如:V1.0.16V1.0.27V1.0.101(如果FOO-16FOO-27和{ {1}}被选中) - Flyway不在乎。所有未达到稳定版本的功能FOO-101(例如1.0)都应重命名为目标下一个主要版本(例如V1.0.35)。

答案 1 :(得分:20)

我见过最好的方法来克服分支之间的版本问题以启用outOfOrder并使用时间戳作为版本号

默认情况下,大多数迁移框架选择使用整数为各个迁移添加前缀,如下例所示。当框架遇到尚未应用于当前数据库的迁移时,它将从第一次迁移开始,该迁移的前缀在数据库中不存在,并开始按升序应用它们。

  • 1.0.0.1__add_customers_table.sql
  • 1.0.0.2__add_email_address_column_to_customers_table.sql
  • 1.0.0.3__add_orders_table_with_reference_to_customer_table.sql

当每个人都在同一个代码分支上时,这很有用。但是,一旦团队成员开始在他们自己的分支上工作,前缀冲突的可能性就会大大增加。

但是,如果您选择使用时间戳而不是整数为迁移添加前缀,那么即使跨越分支,冲突的可能性也几乎消失。例如,使用诸如 yyyyMMddHHmmssSSS 之类的模式,上面的迁移现在看起来像......

  • 1.0.0.20130704144750766__add_customers_table.sql
  • 1.0.0.20130706132142244__add_email_address_column_to_customers_table.sql
  • 1.0.0.20130706151409978__add_orders_table_with_reference_to_customer_table.sql

上面的时间戳模式精确到毫秒。虽然高度精确的时间戳会导致难以读取的前缀,但前缀越精确,碰撞的可能性就越小。

为了获得最佳效果,您需要自动创建此时间戳,以便团队中的所有成员都使用一致的格式

此外,请注意,Flyway还将时间戳前缀视为整数。这意味着如果您最初使用整数开始使用Flyway,那么您仍然可以在任何时候切换到时间戳。由于时间戳只是非常大的整数,因此第一个时间戳前缀迁移将在最后一个整数前缀迁移后应用。

从这里采取并稍加修改:http://www.jeremyjarrell.com/using-flyway-db-with-distributed-version-control/

答案 2 :(得分:1)

使用时间戳作为版本似乎是个好主意。我看到的唯一问题是团队遍布全球。在这种情况下,我们可能必须选择一个时区作为标准。