39

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

在 Flyway 中是否有处理此问题的标准方法？我已阅读常见问题解答，其中讨论了对生产数据库的更改如何是线性的，这是正确的。但是，我不确定团队成员在他们的功能分支上工作时将如何决定为他们的迁移提供哪些版本号。此外，当我们在发布前合并到集成分支和 master 时，我们需要手动重命名迁移文件。

4

3 回答 3

29

我见过的克服分支之间的版本控制问题以启用 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之类的模式，上面的迁移现在看起来像……</p>

  • 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/

于 2016-01-04T20:32:50.823 回答
28

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

发现多个版本为“xyz”的迁移（违规者：SQL ...）

这是我建议的一种解决方法：多个开发人员正在开发相同的版本，比如1.0不同的功能。我猜您正在使用一些问题跟踪器，为每个问题添加 id，例如FOO-16. 当开发人员处理该问题时，将调用迁移脚本V1.0.16__my_greatest_feature.sql。这样（假设每个功能/分支都有自己的问题）没有冲突。

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

因此，在稳定版本中，您有几个迁移脚本存在差距，例如：、、V1.0.16（V1.0.27如果V1.0.101选择了和）- Flyway 不在乎。所有没有成为稳定版本的特性（例如）都应该重命名为下一个主要版本（例如）。FOO-16FOO-27FOO-1011.0V1.0.35V1.1.35

于 2012-02-29T10:21:41.013 回答
0

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

于 2017-09-13T22:17:10.797 回答