使用function分支时如何使用Flyway
我们最近开始使用function分支来处理我们所处理的每个故事。 这些是尽可能独立的，然后我们的项目经理决定哪些故事将构成一个版本。 这意味着我们确实知道故事最初投入生产的确切顺序。
在Flyway有一个标准的处理方法吗？ 我已经阅读了FAQ，它讨论了对生产数据库的更改是如何线性的，这是正确的。 但是，我不确定团队成员如何决定在他们的function分支工作时为他们的迁移提供哪些版本号。 当我们在发布之前合并到集成分支和master时，我们还需要手动重命名迁移文件。
您不能拥有与您将获得的版本号相同的迁移scrtipts：
使用版本’xyz’找到了多个迁移（违规者：SQL …）
这是我建议的一种解决方法：多个开发人员正在使用相同的版本，比如1.0但是使用不同的function。 我想你正在使用一些问题跟踪器，为每个问题添加ID，如FOO-16 。 当开发人员处理该问题时，迁移脚本称为V1.0.16__my_greatest_feature.sql 。 这种方式（假设每个function/分支都有自己的问题）没有冲突。
另外我假设数据库迁移脚本是独立且不重叠的，但如果不是这种情况，那么在将所有内容合并到稳定版本时会遇到问题。
因此，在稳定版本中，您有几个具有间隙的迁移脚本，例如： V1.0.16 ， V1.0.27 ， V1.0.101 （如果选择FOO-16 ， FOO-27和FOO-101 ） – Flyway将无关紧要。 所有未达到稳定版本1.0 （例如V1.0.35 ）的function都应重命名为目标下一个主要版本（例如V1.1.35 ）。
我见过的最好的方法是克服分支之间的版本问题以启用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/
使用时间戳作为版本似乎是个好主意。 我看到的唯一问题是团队遍布全球。 在这种情况下，我们可能必须选择一个时区作为标准。